Why Keycard
Why AI agents need a new approach to identity, access, and trust
Agents don’t work like apps. They reason, act, and adapt at runtime, calling tools, accessing APIs, reading data, writing code in loops that can’t be predicted at deploy time. Traditional IAM was designed for a world where software follows deterministic paths and humans make the decisions. That world is ending.
The trilemma
Section titled “The trilemma”Every team deploying agents today hits the same tradeoff: autonomy, capability, and security - pick two.
- Give agents full autonomy and capability, and they run freely across systems, leaking secrets, invoking unintended tools, or taking actions that look innocuous until they aren’t.
- Lock things down with human-in-the-loop approval, and you get consent fatigue and constant oversight that erases the productivity gains agents were supposed to deliver.
- Narrow the scope with network-level controls, and agents become autonomous in name only. Brittle, limited, unable to reach the tools they need.
Most teams pick two and constrain the third. The productivity gains these agents can already deliver stay theoretical instead of deployed at scale. Keycard is built to break that tradeoff.
Why it’s broken
Section titled “Why it’s broken”The problem isn’t the agents. It’s the infrastructure underneath them.
Agents inherit the user’s full token or a shared service account. There’s no way to scope, revoke, or trace what the agent did versus what the user did. Credentials are long-lived and shared across agents, repos, and environments with no per-task scoping, no attestation, no expiration.
There’s no enforcement layer between the model’s decision and the action. Prompt injection redirects tool calls, and security teams have no runtime control. No structured audit exists across sessions or tool calls. Incident response ends with “we don’t know.” Without visibility, trust never builds.
These gaps exist because existing IAM architectures - RBAC, conditional access, network-layer controls - were built for deterministic software and human decision-makers. Agents break every assumption they depend on.
What Keycard does differently
Section titled “What Keycard does differently”Keycard is identity and access infrastructure built from the ground up for agents. It resolves identity, enforces policy, issues scoped credentials, and logs everything - at runtime, on every tool call.
Users, agents, and workloads each get a verified identity. Agents prove who they are through workload attestation - SPIFFE, cloud instance identity, mTLS - combined with the delegating user, the device, and the task for composite identity.
Policy evaluates at credential issuance, not at login or the network boundary. Every tool an agent touches - shell commands, MCP servers, APIs, agent-generated code - is governed at the point of execution. No credential is issued without policy approval.
Static secrets are replaced with ephemeral tokens cryptographically bound to the agent, the user, the runtime environment, and the task. Credentials are injected in-memory, never touch disk or the agent’s context window, and expire when the session ends. Every hop from user to agent to sub-agent to tool is traced. When something goes wrong, the audit trail shows exactly who authorized what, through which chain, at what time.
Routine actions proceed without interruption. Sensitive operations -
deploying to production, accessing restricted data - trigger step-up
approval from the developer. No consent fatigue. No blanket
--dangerously-skip-permissions.
Keycard extends your existing identity providers (Okta, Auth0, Google) to cover agents. It doesn’t replace your IdP - it bridges the gap between human identity and agent access across trust domains.
The result
Section titled “The result”Teams stop choosing between autonomy, capability, and security. Agents get the access they need, scoped to the task, enforced by policy, and logged for everything. The organization gets agents that are actually deployed in production.