How Keycard Works
Understand how Keycard controls access in agentic, federated systems.
Keycard is a unified identity and access managment (IAM) platform that governs human and agent access to resources. While it excels at traditional identity management, it is designed to enable trusted collaboration between people and agents.
This guide covers the core architecture, detailing how the platform provides an identity fabric that controls access in human-to-agent, agent-to-agent, and agent-to-service scenarios, across highly-federated and open ecosystems while preserving complete delegation chains.
Agentic Access Loop
Section titled “Agentic Access Loop”When a person gives an agent a task, the agent enters a loop of reasoning and acting. The agent thinks about the information it has and determines which set of tools it can use to make progress toward its goals. The agent uses these tools, which supply it with more information - more context - which it incorporates in a continuous cycle.
This dynamic approach allows agents to adapt to new information and unexpected obstacles, unlike traditional software with predefined, deterministic workflows. As software becomes more human-like - more artificially intelligent - people are able to delegate more tasks, more effectively. At the same time, the more agents act on their own, the more security controls are needed to effectively govern access.
Keycard secures agentic access by introducing an access loop into the agentic loop:
Authorization Challenge
Section titled “Authorization Challenge”When an agent uses tools, it is accessing resources. These resources could be tools exposed directly via AI-native protocols such as MCP, existing web APIs accessed via HTTP, or databases accessed through CLIs and TCP-based protocols.
In order to ensure security, the resource must verify that the agent is authorized to perform the operation it is requesting. This requires the agent to present a credential, often referred to as an access token, which provides a set of claims regarding the identity of the agent, who authorized the agent, and which actions the agent is allowed to take.
If the agent does not present a credential (the agent is unauthenticated) or the credential presented is insufficient (the agent is unauthorized), the resource responds with an authorization challenge to inform the agent of its status. This causes the agent to request authorization from an authorization server.
Authorization Request
Section titled “Authorization Request”In order to obtain a credential permitting access to a resource, an agent makes an authorization request to an authorization server. The authorization server is responsible for authenticating the agent, as well as the person it is acting on behalf of (if any), and evaluating whether or not the agent and person are authorized to access the desired resource.
At the core of Keycard is Keycard STS, short for Security Token Service. Keycard STS is an authorization server, and is responsible for authenticating people and agents and authorizing their access to resources. Keycard STS implements OAuth 2.0, an industry-standard authorization protocol, along with a suite of extensions.
Policy Evalutation
Section titled “Policy Evalutation”When Keycard STS receives an authorization request, it initiates a sequence of challenges, the responses to which are needed to obtain the necessary information required to authorize the request. When authorizing a person, the challenges consist of prompts to login, step-up authentication, and grant consent. When authorizing an agent, the challenges consist of authenticating the agent’s identity, attesting to its software environment, and, if required, bringing a human into the loop for approval.
As each challenge and response is completed, policy is evaluated against the current authorization context. The authorization context contains information about the person: identity, level of authentication, and device posture. It also contains information about the agent: identity, software attestation, and delegated authority.
Policy can permit access, deny access, or trigger additional challenges.
Credential Issuance
Section titled “Credential Issuance”Assuming the agent is authorized, Keycard STS issues a credential, often referred to as an access token. The agent then presents this credential to the resource it is accessing, thereby permitting access.
This sequence creates an access loop within the agentic loop, wherein resources are placed under the protection of an authorization server. The authorization server provides a centralized point from which to control access, ensuring that agents are properly authenticated and authorized according to policy.
Identity & Access
Section titled “Identity & Access”Keycard can be used to manage access using core identity concepts: users, applications, and resources. Each of these entities exist within a security boundary called a zone.
A zone is a logical grouping of users, applications, and resources that share a common set of security controls and policies. A zone has two primary responsibilities:
- Authenticating users and applications.
- Authorizing access by users and applications to resources.
In order to fulfill these responsibilities, a zone is both a credential verifier and a credential issuer. A zone verifies authentication credentials presented by users and applications and issues access credentials that authorize access to resources. Resources validate credentials issued by a zone, thereby ensuring end-to-end access control.
Every Keycard zone has an instance of Keycard STS.
& Apps
Keycard STS
IssueUsers are people who access protected resources, either directly or by delegating access to agents that act on their behalf.
Users establish a set of credentials that allow them to authenticate to a zone. In the case of credentials using shared secrets, such as a password or one-time password (OTP), the zone is both the issuer and verifier of the credential. In cases where credentials employ cryptographic key pairs, such as passkeys, the public key is registered with the zone, while the private key remains in the user’s posession.
Applications
Section titled “Applications”Applications are software that access protected resources, either autonomously or as a result of a user delegating access to the application.
Applications establish a set of credentials that allow them to authenticate to a zone. Commonly, an application is issued a client ID and secret by the zone. The zone verifies this secret when authenticating the application. Applications can also register a public key with the zone, avoiding use of shared secrets.
Resources
Section titled “Resources”Resources are any service which exposes protected data. Resources take many forms, including web APIs, MCP servers, and databases. More generally, they are any service which makes access available via a network protocol, such as HTTP, FTP, or SSH.
Resources validate credentials issued by a zone when they are presented by applications requesting access. This validation ensures that end-to-end access control is enforced.
Federation
Section titled “Federation”Keycard’s core access management capabilities can be extended to support federated ecosystems using an additional concept: providers. Providers represent trust relationships with other security domains. Such relationships allow access between a zone and an external domain in what is referred to as federation.
e.g. Okta, Entra
e.g. AWS, GCP, Vercel
e.g. GitHub, Slack
User Identity Providers
Section titled “User Identity Providers”Providers can assert the identity of users. Such providers are referred to as identity providers (IdPs). IdPs allow a single set of credentials to be used to authenticate to the provider, while simulataneously allowing the underlying identity to be used in other domains. IdPs reduce password fatigue for users and streamline management for administrators.
In enterprise scenarios, this is referred to as single sign-on (SSO), allowing employees to sign in using their corporate IdP, such as Okta or Microsoft Entra. In consumer situations, this is known as social login, and enables people to sign in with an existing account at Google, Apple, or a social network.
Adding a user identity provider to a zone allows users to authenticate to the zone via the IdP. Keycard supports standard federated identity protocols, including OpenID Connect and SAML.
Application Identity Providers
Section titled “Application Identity Providers”Providers can assert the identity of applications.
Applications that run on cloud infrastructure are referred to as workloads. Cloud service providers (CSPs) can assert the identity of these workloads. As a result of this terminology, CSPs are often referred to as workload identity providers. Adding a workload identity provider to a zone allows applications to authenticate to the zone using their workload identity, eliminating the need for service accounts with long-lived secrets.
Keycard supports workload identity from major cloud providers, including Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Vercel, and GitHub Actions.
Access Credential Providers
Section titled “Access Credential Providers”Services which issue access credentials for resources hosted by third-parties are access credential providers. Adding an access credential provider to a zone allows the zone to broker credentials for external resources.
Keycard supports brokering via a wide variety of mechanisms. Most commonly, delegated access tokens are vaulted and brokered to services. OAuth 2.0 token exchange can be used to support cross domain access while reducing consent fatigue for users. Provider-specific programmatic access interfaces are also supported. Keycard normalizes these differences, providing a standard way for applications to request credentials.