Verifiable Identity and Delegated Authority for AI Agents (Know Your Agent)

As AI agents transition from read-only information retrieval to executing transactions across databases, APIs, and payment rails, verifiable agent identity becomes necessary for governing what those agents are authorized to do.

Reflecting on a recent panel at the C:\>DIR Summit hosted by Financial Innovation for Impact (Fii) and the Cambridge Centre for Alternative Finance (CCAF), Lotte Schou Zibell captured the core governance challenge:

"We need to 'know our agents.' If an AI agent acts on someone’s behalf, it needs a clear and verifiable mandate. We must know which agent is acting, what it may access or initiate, where its authority ends, and who is accountable when something goes wrong... Across identity, data and payments, trust must be supported by reliable verification and predictable execution. People need confidence that an instruction came from the right person or agent, authorised data were used, and a payment was executed as intended."

In practice, most enterprise deployments are nowhere near this standard.

According to CCAF’s 2026 Global AI in Financial Services Report, 28% of financial services-specific AI products already operate fully autonomously (human-out-of-the-loop). Yet that autonomy currently rests on internal, vendor-siloed domain logic and static rules (regulatory rules, risk thresholds, compliance guardrails) not interoperable, verifiable authority.

Relying on vendor-level guardrails is not a sustainable risk posture. Without verifiable cryptographic identity and delegation frameworks, these boundaries remain brittle promises rather than mathematically enforceable constraints.

In emerging multi-agent environments, where agents autonomously delegate tasks, authorize sub-agents, and execute actions across organizational and system boundaries, each step introduces a need to establish the identity of the actor, trace the authority under which it is operating, and verify the scope of the mandate it has been given.

Consider a relatively simple workflow:

The organization authorizes an orchestrator to perform a workflow. The orchestrator delegates part of that workflow to a specialist agent, which eventually requests an action against an enterprise system.

For example, a commercial bank's treasury system establishes liquidity risk rules, authorizing an Orchestrator Agent to monitor intraday cash reserves. When event detection flags a $50M settlement shortfall that human latency cannot address in time, the orchestrator issues a sub-task to a Collateral Specialist Agent to source short-term funding. The specialist executes the optimal repo swap directly against the bank’s Core Payment Gateway, relying entirely on the vendor's embedded compliance guardrails and hard-coded thresholds to keep it within bounds.

Because those boundaries live inside vendor silos rather than as an interoperable, verifiable chain of delegation, the enterprise audit trail shows an execution without cryptographic proof of which specific agent acted, the provenance of its mandate, or mathematically enforceable constraints.

At execution time, the organization needs to verify the entire chain of authority, not just the identity of the agent initiating the call.

The organization needs to be able to determine:

• Which agent initiated the request?
• Which principal ultimately authorized it?
• How was authority delegated through the agent hierarchy?
• What limits apply to that authority?
• Is the delegation still valid?
• Is the proposed action permitted under current policy and context?

We have been exploring this problem at Data Sense for some time while developing SimBI, an Autonomous Decision Infrastructure designed to evaluate proposed AI actions before they reach downstream systems.

One technology we are investigating as part of that architecture is KERI.

KERI and self-certifying identity

KERI, or Key Event Receipt Infrastructure, provides a framework for cryptographically verifiable identifiers and key-state management.

Its Autonomic Identifiers, or AIDs, are self-certifying. Rather than relying exclusively on a central identity provider to assert the identity associated with a request, the identifier can be cryptographically resolved against its associated key history.

KERI maintains this history through Key Event Logs, recording events associated with the identifier and its cryptographic state.

Rather than relying on a global blockchain, KERI functions as a cryptographically verifiable micro-ledger for each identifier. The architecture enables immutable provenance across key rotations, delegations, and authority assignments.

For autonomous agents, this creates the possibility of assigning cryptographically verifiable identities to the each agent participating in a workflow, without distributed consensus overhead.

An architecture could therefore begin with an a principal and cryptographically delegate authority to and orchestrator who cryptographically delegates authority to a specialist agent.

Each participant now has a cryptographically verifiable identity, with delegation relationships that can be traced back through the chain of authority. This provides part of the technical foundation for what is increasingly being described as Know Your Agent (KYA).

Know Your Agent (KYA) is a governance discipline for financial institutions that requires every material AI agent to be uniquely identified, classified by role and authority, bound to named human owners, and continuously monitored so that its delegated decision‑making scope, data/system access, and actual behavior are evidenced, controlled, and re‑reviewed on a defined cadence.

For those coming from an AML environment, the similarity with Know Your Customer (KYC) will be familiar. Before an institution can govern what an agent is permitted to do, it first needs a reliable way to establish which agent it is dealing with and the authority under which it is acting.

KERI provides cryptographic evidence for that identity and delegation chain. It does not, by itself, define the boundaries of what the agent is permitted to do.

That brings us to the next part of the architecture: delegation also needs scope.

We go further into the KYA model, including an AML example in financial services, in this forthcoming SimBI technical article [coming soon], which will form part of the broader ADI white paper.

Delegation also needs scope

Establishing a verifiable delegation relationship only addresses part of the problem. We also need to establish what authority was actually delegated, such as: which resources the agent can access, which actions it can perform, under what conditions, and where that authority ends.

Knowing which agent initiated an action and tracing its authority back to a principal establishes identity and provenance. Governing that agent also requires evidence of the scope and constraints attached to its delegated authority.

An organization authorizing an orchestrator does not necessarily authorize every action that orchestrator could technically perform. Similarly, an orchestrator delegating work to another agent may want to constrain that delegation.

This is already emerging as a practical requirement in discussions around non-human identity governance. The Non-Human Identity Management Group (NHIMG), for example, recommends that organizations:

“Define delegated authority boundaries. Scope each agent to the minimum set of actions it needs for a specific use case, then document what it cannot do.”

NHIMG extends this into the broader KYA control environment, recommending that organizations capture the agent’s identity, policy decision and downstream action for subsequent review, and integrate KYA controls into existing Identity and Access Management (IAM) and Privileged Access Management (PAM) governance.

The architectural question is then how those boundaries can be represented in a form that is verifiable by the systems receiving an agent’s request.

This is where Authentic Chained Data Containers (ACDCs) can be used to represent evidence about delegated scope.

ACDCs provide a mechanism for establishing cryptographically verifiable provenance over data and credentials. For agent delegation, they can also represent chains of delegated authority.

As the ACDC specification describes:

“A proof-of-authority may be used to provide different types of verifiable authorizations such as, entitlements, permissions, rights, or credentials. A chained (treed) proof-of-authority enables delegation of authority and hence delegated authorizations.”

Within the SimBI architecture, this gives us a way to attach verifiable evidence to the authority being exercised by an agent. An ACDC credential could represent attributes such as permitted resources, transaction limits, expiry periods, roles, or other constraints associated with that delegation.

In an institutional setting, those attributes might describe constraints such as:

• permitted resources
• authorized operations
• transaction limits
• applicable jurisdictions
• expiry periods
• organizational roles
• database access

Consider our treasury workflow example from earlier.

A treasury function authorizes an orchestrator agent to monitor intraday cash reserves. The orchestrator delegates part of that workflow to a specialist agent responsible for analyzing transaction and account-balance data to determine the organization’s intraday cash position.

With KERI, the specialist agent’s identity and its delegation relationship can be cryptographically verified. Associated ACDC credentials can provide evidence of the authority under which it is operating, including constraints attached to that delegation.

The specialist agent then proposes an action: query the organization’s Treasury Management System (TMS) for the transaction and account-balance data required to calculate the current cash position.

The request is signed by the specialist agent and verified against its KERI identity and current key state. Its delegation chain can be traced through the relevant KERI events, while its ACDC credentials provide verifiable evidence of the authority and constraints associated with that delegation.

The risk is an agent without the appropriate credentials, or operating outside the scope of its delegated authority, could gain access to sensitive transaction, account, or customer information.

The proposed TMS access therefore needs to be evaluated against the policies and conditions governing that specific action before the query is executed.

Identity becomes runtime context

Establishing identity, delegation, and the scope of that delegated authority gives SimBI the evidence it needs to evaluate who is proposing an action and the authority under which they are acting.

When an agent proposes an action, SimBI resolves this evidence as part of the runtime context used to make an authorization decision. The agent’s verified identity, delegation chain, and associated credentials are evaluated alongside the organization’s policies and other relevant context, such as the requested resource, purpose, data permissions, and current system state.

The resulting decision is therefore tied to a specific agent, acting under a specific delegation, with defined authority, proposing a specific action under the policies and conditions that apply at that point in time.

Conceptually:

Within SimBI, this process is separated into two functions: resolving the information required to evaluate the action, and making the decision itself.

The Policy Information Point (PIP) handles the first part of this process.

NIST defines the PIP as the retrieval source for the attributes and data required by the Policy Decision Point (PDP) to evaluate a policy decision.

In the SimBI architecture, we extend this model to the context required for an agent action. The PIP resolves the agent’s verified identity and delegation chain, relevant ACDC credentials, the resource being requested, and other contextual information required by the organization’s policies.

This follows the broader Attribute-Based Access Control (ABAC) model described in NIST SP 800-162, where authorization decisions can incorporate attributes associated with the requesting subject, the resource being accessed, the requested operation, and environmental conditions.

The PIP might therefore resolve that:

• the request was signed by Specialist Agent "A";
• Specialist Agent "A" was delegated authority by Orchestrator "B";
• the delegation ultimately traces back to Principal "C";
• the agent holds a valid credential associated with a particular resource and purpose;
• the proposed action is requesting access to Resource X; and
• additional conditions relevant to that resource are currently in effect.

This resolved context is then passed to the Policy Decision Point (PDP).

The PDP evaluates the proposed action and resolved context against the organization’s deterministic policies. These policies define the conditions under which an action can proceed, rather than leaving the authorization decision to the agent or the LLM that generated the request.

A policy could require, for example, that an agent accessing a financial system has a valid delegation from an approved principal, holds the appropriate credential, is requesting an authorized resource for an approved purpose, and remains within any limits attached to that authority.

The PDP then produces a "DecisionResult", such as ALLOW or DENY, together with the policy and contextual evidence used to reach that decision.

Returning to our treasury example, the full chain now looks like this:

1) Establish identity and delegation

A treasury function authorizes an orchestrator agent to monitor intraday cash reserves. The orchestrator delegates part of that workflow to a specialist agent.

KERI provides the cryptographic basis for verifying the specialist agent’s identity and tracing its delegation relationship back through the orchestrator to the originating principal.

2) Establish evidence of delegated authority

The specialist agent holds an ACDC credential providing verifiable evidence that it has been granted authority to access the Treasury Management System (TMS) for a defined purpose, such as treasury.cash_position_monitoring.

3) Agent proposes an action

The specialist agent signs and submits a proposed action requesting transaction and account-balance data from the TMS to calculate the organization’s current cash position.

4) SimBI resolves the organization’s applicable policy and context

Through the PIP, SimBI resolves the information required to evaluate the proposed action against the organization’s applicable policies. These policies could contain rules like:

• TMS access requires a valid treasury credential.
• Access is permitted for intraday liquidity monitoring.
• Only specified datasets/fields may be queried.
• Customer-level data cannot be returned.
• Queries above a certain sensitivity require human approval.
• Credentials must be current and tied to the requesting agent.

5) SimBI evaluates the proposed action

The PDP evaluates whether the authenticated agent, its verified delegation and credentials, the requested resource, purpose, parameters, and current context satisfy the organization’s applicable policies.

The identity and delegation evidence therefore becomes an input into a broader runtime authorization decision.

An existing institutional precedent

This approach to verifiable identity and delegated authority already has an institutional precedent.

KERI provides the cryptographic foundation for the verifiable Legal Entity Identifier (vLEI) ecosystem.

The vLEI extends organizational identity into cryptographically verifiable credentials and roles, providing a useful precedent for how identity and authority can be represented digitally across institutional boundaries.

AI agents extend this problem further. If autonomous software is going to act on behalf of an organization, organizational authority needs to extend to those agents in a form that other systems can independently verify.

GLEIF CEO Alexandre Kech has written about this directly, including the potential role of vLEIs in establishing verifiable organizational identity for AI agents.

Other work is converging on similar requirements. In Authenticated Delegation and Authorized AI Agents, researchers from Stanford, MIT and elsewhere propose an authenticated delegation framework built primarily around existing OAuth 2.0 and OpenID Connect infrastructure.

Their implementation differs from the KERI and ACDC architecture explored here, but the underlying requirements overlap considerably: an agent needs a verifiable identity, its authority needs to trace back to a principal, that authority needs an explicit scope, and third parties need a way to verify those claims before granting access.

That leaves several architectural questions:

• How should an agent's mandate be represented?
• Which authority can be delegated further?
• How should transaction limits, purposes, and expiry be expressed?
• How should delegated authority be withdrawn?
• What happens when agents operated by different institutions interact?
• How should organizations translate human instructions into sufficiently precise, machine-enforceable permissions?

These questions will become increasingly relevant as agents gain access to enterprise data, systems, and workflows.

Our current work with SimBI is exploring KERI and ACDCs as part of the identity and delegated-authority layer of this architecture. KERI provides a cryptographically verifiable basis for establishing who an agent is and the delegation chain under which it operates. ACDCs provide a mechanism for representing evidence about the authority attached to that delegation. SimBI can then incorporate that evidence into the runtime evaluation of the actions agents propose.

For readers interested in the implementation, we go deeper in a forthcoming SimBI technical article covering the proposed trust model, KERI primitives, delegation lifecycle, runtime policy evaluation, and how this identity and authority layer connects with the broader Autonomous Decision Infrastructure architecture.

Technical article: [link]

Part of the SimBI research series by Data Sense.