Know Your Agent: How to Bind a Human to an AI Agent

Key takeaways

• Know Your Agent (KYA) is not solved by naming an agent. The durable control is a delegation chain that links an authenticated person, a registered client, granted scopes, an organization context, and each resulting action.
• Didit’s hosted Model Context Protocol (MCP) endpoint exposes 115 tools across 19 domains and uses Open Authorization (OAuth) 2.1 with Proof Key for Code Exchange (PKCE) and Dynamic Client Registration.
• The MCP acts as the signed-in Didit user. It inherits that user’s organization role, so a connected agent cannot gain permissions that the person did not already have.
• An application key stored in a configuration file proves possession of a credential, not which human delegated a particular action. Shared keys collapse multiple operators and agents into one application identity.
• Accountability requires both enforcement and evidence: scoped tokens and role checks before an action, then audit records that show who changed what.

Didit has already shipped the mechanism. Its hosted MCP server connects an AI client to identity and fraud operations through a signed-in user, rather than treating the agent as an anonymous holder of an application secret. The endpoint is free, uses stateless Streamable HTTP, and exposes 115 tools. The implementation is also available in the public MIT-licensed GitHub repository.

That artifact changes the useful question. Instead of asking for another definition of KYA, ask: when an agent creates a verification session, reads a decision, or changes workspace data, what proves which person authorized it, what that person allowed, and which organization accepted the action?

Human binding is a delegation chain

An agent name, model identifier, public key, or software attestation can help identify the machine actor. None of them, on their own, establish who is accountable for what the agent does. Human binding needs a chain with distinct links:

• Principal: the authenticated user or service owner on whose behalf the agent acts.
• Client: the AI application that requested access.
• Delegation: the scopes and consent granted to that client.
• Authorization context: the organization role and application boundary applied to the request.
• Evidence: a reviewable record of the action and its result.

Each link answers a different question. Authentication says who signed in. OAuth says which client received delegated access. Scopes say which classes of operation were approved. Roles say what the user may do inside the organization. Audit records say what actually happened. Collapsing these controls into a single “verified agent” badge hides the most important part: authority is contextual and revocable.

A trustworthy agent is not merely identifiable. It must be able to show an unbroken path from an accountable principal to a specific, permitted action.

Why a key in a config file fails the accountability test

An application API key can be appropriate for a controlled server-to-server integration. It is not, by itself, a human-to-agent binding mechanism. A copied key normally answers one question: “Does this caller possess a credential accepted for this application?” It does not answer who launched the agent, who approved the current task, or whether two calls using the same key came from different people.

The failure modes are predictable. Teams share a key across local environments. An agent process inherits it from a configuration file. A second agent receives a copy. Logs then attribute every call to the same application credential. Revoking that credential interrupts every workload that uses it, while leaving the individual delegation event unclear.

Didit deliberately does not offer an application-key path for its hosted MCP endpoint. Backend integrations can still use Didit’s REST APIs with application credentials, but remote MCP access requires a user OAuth flow. That separation matters: the REST credential represents an application integration; the MCP token represents delegated access from a signed-in user.

OAuth 2.1, PKCE, and Dynamic Client Registration

OAuth is the delegation primitive in this design. The flow does not hand the user’s password to the agent, and it does not place a reusable platform secret in the MCP configuration. Instead, the AI client obtains a limited access token after the user authenticates with Didit and approves access.

1. Register the client

Dynamic Client Registration lets a compatible MCP client register with the Didit authorization server without a manually pre-provisioned client identifier. This gives the authorization server a distinct client registration to which it can issue access. Registration identifies the OAuth client; it does not, by itself, certify that the client’s software is trustworthy.

2. Bind the authorization response to the client

PKCE creates a one-time verifier and challenge for the authorization attempt. The client that starts the flow must present the verifier when exchanging the authorization code. This limits the value of an intercepted code because another process cannot redeem it without the verifier.

3. Authenticate and consent

The user signs in at the Didit Business Console, which acts as the authorization server, and approves the requested scopes. Didit advertises didit:verification for verification operations and didit:management for workspace management. A client should request only the scope required for the task.

4. Validate every call

The hosted MCP resource server validates the bearer token before dispatching a tool call. The validated user token and organization context travel with the request to Didit. The downstream service then evaluates the existing role and permissions for that user. The result is acting-as-user semantics, not a new superuser identity created for the agent.

The MCP authentication guide documents the flow, while the MCP overview explains the hosted endpoint and client model.

Acting as the user makes authority legible

Suppose a compliance operator connects an AI client to Didit. The client first calls didit_context_get, which returns the organizations and applications that the signed-in user can access. If the user has one unambiguous organization and application, the context can resolve automatically. If several are available, the operation can be narrowed to an explicit organization and application.

The agent can then call didit_session_create to create a verification session and didit_session_get_decision to retrieve its outcome. Those are real domain-first tool names in the current MCP catalogue. A user who lacks the required permission does not gain it by connecting an agent; the same organization authorization boundary still applies.

This is the central difference from a shared application credential. In the OAuth model, the request arrives as a known user operating through a registered client with declared scopes. In the shared-key model, the downstream system sees the application credential, while the human and the agent behind a particular call remain indistinguishable unless a separate control plane supplies that context.

Auditability: from “who can act?” to “who did what?”

Authorization prevents an out-of-scope action. Auditability explains an action after it occurs. Didit exposes didit_audit_log_list so an authorized user can inspect application audit entries describing who changed what. Because each hosted MCP request carries the signed-in user’s bearer token and resolved organization context, the action is attributable to that caller rather than to an anonymous agent process.

A complete forensic record should also preserve agent-side evidence. For high-impact workflows, record the agent run identifier, client registration, requested scope, target organization and application, tool name, timestamp, approval state, and a safe representation of inputs and outputs. Do not log access tokens or sensitive identity payloads. The platform audit trail and the agent execution log should be correlatable without duplicating secrets or regulated personal data.

Attribution is not the same as non-repudiation, and an audit log is not a substitute for least privilege. The controls reinforce one another:

• Use short-lived access and controlled refresh rather than permanent shared credentials.
• Grant the narrowest OAuth scope and the least-privileged organization role.
• Require human confirmation for destructive or unusually high-impact operations.
• Keep organization and application context explicit when more than one target is available.
• Revoke the user session or client grant when the delegation should end.
• Monitor audit records for unexpected actors, tools, targets, or timing.

What the binding proves—and what it does not

This pattern proves that an authenticated Didit account delegated scoped access to an OAuth client and that each request is evaluated with that user’s organization permissions. It creates practical accountability to an account and a reviewable chain for platform actions.

It does not automatically prove that the account holder has a verified civil identity, that the approved client binary has not been modified, or that the human is actively watching every step. Those require additional assurance. If legal-identity assurance is necessary, verify the principal during onboarding with Know Your Customer (KYC) controls and bind that result to the account. If software provenance matters, add client attestation and signed releases. If presence matters, require step-up approval at the moment of the sensitive action.

This layered view keeps KYA honest. Agent identity, human identity, delegated authorization, runtime policy, and audit evidence are related controls, not interchangeable labels.

A worked implementation you can inspect

Didit’s implementation provides a concrete reference for teams designing the same accountability boundary. The hosted server authenticates as the signed-in Didit user, inherits that user’s organization role, and applies that identity to every tool call. Its 115 hosted tools span 19 domains, from context and verification sessions to workflows, organizations, analytics, and audit logs. The current tool catalogue lists the exact surface.

For product context, the full KYC bundle costs $0.33 and combines ID Verification, Passive Liveness, Face Match, and IP Analysis. Didit includes 500 free verifications per month and is used by 2,000+ companies in production. The MCP server itself is free, so teams can evaluate the delegation and permission model without adding a separate connector fee.

To see how this mechanism fits into broader agent workflows, read how the identity and fraud MCP works for AI agents and the Didit MCP tool reference.

Bind the agent before you trust the action

The hard problem in agent identity is not inventing a durable name for software. It is preserving human accountability as software crosses interfaces and acts at machine speed. OAuth 2.1 supplies delegated access. PKCE protects the authorization exchange. Dynamic Client Registration identifies the connecting client. Scopes and organization roles constrain authority. Audit records make the result reviewable.

You can inspect the architecture in the Didit MCP repository, review the authentication documentation, or connect Didit to Claude. The useful test is simple: for any proposed agent action, can you identify the accountable user, the client, the granted scope, the organization boundary, and the resulting audit evidence? If any link is missing, the agent is not fully bound.