Agentic Attestation And The Problem Of Who Is Asking
The future challenge around handling agent identity attestation.
Shaun Archer
10/29/202618 min read
A person calls the helpdesk because they have lost access to their account. They know the employee’s name, their manager, their team and enough about the business to sound credible. They need their MFA reset, and they need it done quickly.
An agent arrives at an API with a similar request. It presents a valid credential, identifies the agent that spawned it and explains that it is acting on behalf of an employee. It needs access to complete a task.
Both requests bring us back to the same problem. What evidence should be enough to establish who is asking, who authorised them and whether we should allow the action?
We have spent years building ways to answer these questions for humans. We have also built mechanisms for applications, services and workloads. Agents bring those worlds together, while removing some of the assumptions that make each manageable.
A human usually has a history. A conventional workload usually has a reasonably well-defined purpose. A newly spawned agent might have neither a personal history nor a predictable sequence of actions. It may exist for thirty seconds, delegate part of its task and disappear before anyone reviews what it did.
I think this is where agentic attestation becomes an important part of identity security. By that, I mean establishing verifiable evidence about an agent’s origin, its operating context and the authority behind a particular action, including its identity where it has one.
That last qualification matters. Some agents need a distinct security identity. Others can operate within an application that holds and enforces the relevant authority. We should decide which boundary we need before creating another identity to manage.
We also need to be precise about what the evidence actually proves. A valid identity can still be compromised. An authorised agent can still misunderstand its task. An authentic piece of software can still do something harmful.
The design has to account for all three.
1. What we actually prove when a human signs in
Before getting into agents, it helps to separate the decisions we already make around human identity.
Identity proofing establishes the relationship between a person and a claimed identity. In an employment context, that involves the organisation’s hiring and onboarding processes, supported by whatever evidence and checks are appropriate.
Authentication is what happens when that person returns and claims the identity again. We traditionally organise authentication around three types of evidence.
Something you know — a password, passphrase or PIN.
Something you have — an authenticator such as a security key, smart card or a device holding a cryptographic credential.
Something you are — a biometric characteristic, such as a fingerprint or facial pattern.
Multi-factor authentication combines distinct factor types. Two passwords remain one factor type. A fingerprint activating a cryptographic authenticator can combine something you are with something you have. NIST does not recognise a biometric characteristic as an authenticator on its own. Each factor has limits too. Knowledge can be disclosed, possession can be stolen, and biometric comparisons can be deceived or produce false matches. NIST’s authentication guidance explains these distinctions.
Authorisation is the next decision. Being an authenticated employee does not automatically authorise someone to administer the identity provider, approve a payment or export customer data. Those decisions depend on roles, policies, resource ownership and the circumstances of the request.
Attestation adds an assertion supported by evidence. A manager might attest that someone works in their team. A device service might attest to properties of the device being used. An access review might ask an owner to attest that a permission remains appropriate.
These assertions answer different questions. A manager recognising an employee does not establish that their laptop is healthy. A healthy laptop does not establish that a payment has been approved.
That separation becomes particularly important when the normal authentication process breaks down. The helpdesk may be dealing with someone who has forgotten what they know, lost what they have, or cannot use their usual biometric authenticator. It still needs enough evidence to make a safe recovery decision.
2. The helpdesk has to make the hardest identity decision
The helpdesk is asked to make an identity decision precisely when the person cannot present the evidence we normally expect. They have lost their phone, replaced their laptop or become locked out of their account. The recovery process has to bridge that gap.
Attackers understand this. Singapore’s Cyber Security Agency documented Scattered Spider impersonating employees and providing correct answers to verification questions when requesting password or MFA resets. The attacker’s objective was to persuade the organisation to replace the legitimate user’s authentication mechanisms with ones the attacker controlled. The advisory describes the practical consequences of weak recovery verification.
The opportunity is to give that decision a much deeper understanding of the user.
Knowing someone’s job title, office location and manager is relatively weak evidence. Those details may be available through public profiles, company websites, previous breaches or a convincing conversation with a colleague.
An organisation can potentially draw on much richer context. It can understand a person’s working relationships, recent activity, usual devices and the systems they interact with. Some of that information will be difficult to obtain through open-source intelligence.
A challenge based on recent private working context may be harder for an external attacker to answer than one based on a directory entry. For example, recognising a recent collaboration or distinguishing a real working relationship from plausible alternatives could provide useful evidence.
That is worth exploring. But “non-OSINTable” needs careful treatment.
3. Private knowledge helps, but we need to understand what it proves
Information being unavailable on the public internet does not make it exclusively available to the legitimate user. A compromised mailbox could expose calendar events. A colleague could know the answer. An attacker might have already accessed the collaboration platform from which the question was generated.
There is also a difference between an answer that sounds obscure and one that is difficult to infer. A multiple-choice question can reveal the relevant information through its wording or its alternatives. Several questions drawn from the same compromised source may add very little independent assurance.
The security property we need is resistance to the attacker we expect to face.
Private contextual questions sit broadly within the idea of something the user knows, but they are not equivalent to a deliberately established authentication secret. Knowing who attended a meeting may support a recovery decision. It does not give us the same evidence as proving control of a registered authenticator.
Answering several contextual questions also does not turn the process into multi-factor authentication. We need to assess what each answer contributes and whether the attacker could obtain it from the same compromised source.
That means testing challenges against strangers, colleagues and attackers with partial access to the victim’s environment. It means measuring how often legitimate users fail, how often attackers succeed and how repeated attempts change those results.
A system that understands the user deeply could improve on a helpdesk process built around static questions and subjective judgement. It could evaluate evidence consistently, select context appropriate to the situation, identify contradictions and record why a recovery decision was made. Whether it actually performs better needs to be demonstrated.
There is an important standards boundary here too. NIST SP 800-63A-4 explicitly prohibits knowledge-based verification and authentication for identity verification within its identity-proofing requirements. Private contextual questions should not be presented as equivalent to stronger proofing methods, or as automatically satisfying an assurance level. NIST’s identity-proofing requirements are explicit on this point.
I would treat contextual knowledge as supporting evidence within a recovery design. Its value depends on the threat model, the quality of the underlying data and the other evidence available.
A safer design would combine that context with established recovery mechanisms and independent signals where possible. NIST describes recovery codes, recovery contacts and repeated identity proofing, with requirements varying by assurance level. Its account recovery guidance provides a useful foundation.
The system also needs to avoid turning recovery into a way to extract private information. An unauthenticated claimant should not be able to keep requesting questions until they have reconstructed someone’s calendar or relationships.
A deep understanding of a person can make verification more informed. It also creates sensitive data that needs protection.
The human case gives us several useful principles. Evidence should be independently checkable. Its value depends on how it could have been obtained. Multiple signals only help when they contribute something meaningfully different. The consequence of the action should influence the assurance required.
We can apply those principles to non-human identities, although the evidence changes.
4. Non-human identities need evidence beyond possession of a secret
Non-human identities include service accounts and the identities assigned to applications, automation, workloads and devices. Strictly speaking, an API key or certificate is a credential used by an identity, although operational inventories often mix the two.
These identities authenticate through mechanisms such as secrets, certificates, signed tokens and workload identity systems. Authorisation comes through permissions, roles and policies associated with the identity and its execution context.
For a traditional application using a shared secret, successful authentication establishes possession of that secret. If the secret has been copied, the legitimate application and an attacker may present exactly the same evidence.
We should be careful about forcing these mechanisms into the human factor categories. A machine presenting two copyable secrets has not necessarily gained the independence we expect from human MFA. The useful question is what each mechanism proves and whether compromising one also compromises the other.
Workload identity can provide a stronger basis for issuance. The platform evaluates evidence about the running workload and issues credentials according to policy. AWS, for example, recommends temporary credentials through IAM roles for workloads rather than distributing long-lived access keys. AWS’s IAM guidance describes this approach.
SPIRE provides another useful example. It performs node and workload attestation against configured conditions before issuing SPIFFE identity documents. The identity decision can therefore depend on observed workload properties and trusted infrastructure. The SPIRE concepts documentation explains the process.
The strength of those mechanisms depends on their foundations. If the issuer, registration policy or underlying platform is compromised, credentials can be issued on a false premise.
Ownership also matters. Someone needs to be accountable for why an NHI exists, which permissions it needs and when it should be retired. An owner can attest that the business purpose remains valid. That assertion does not prove which process is currently presenting the credential.
Again, these are separate decisions.
5. Some agents need an identity, and some do not
An agent is a software actor. Whether it needs its own security identity depends on what it does and where its authority comes from. Where an agent has a distinct identity, that identity is a subtype of NHI.
An agent that reasons over information already supplied to it, produces a draft or breaks a problem into smaller steps may never need to authenticate to another system. Creating a separate identity for every reasoning step or internal sub-agent would add lifecycle and credential management without necessarily creating a useful security boundary.
Other agents operate within an application that authenticates on their behalf. The application may retrieve data, enforce the user’s permissions and execute approved actions through a controlled gateway. The agent has no separately provisioned identity, but its access still depends on an authenticated and authorised application or user.
I think that can be a sensible design. The requirement is that the enforcing system preserves the relevant user, task and execution context, constrains each action and records what happened. Giving every internal component a credential is not a prerequisite for accountability.
A distinct agent identity becomes more useful when the agent independently accesses protected resources, crosses a trust boundary, receives delegated authority or needs permissions and revocation separate from the application hosting it.
Even then, we should distinguish a task or execution identifier from an authentication identity. We may need to trace what a particular execution did without giving it an account, a private key or credentials of its own.
The practical test is whether a separate identity gives us a boundary we need to enforce. Can we restrict this agent independently? Can we revoke its access without disabling unrelated work? Does the receiving service need to distinguish it from other callers?
Where the answer is yes, an agent identity can provide useful control. Where the answer is no, the application may be the appropriate place to hold and enforce authority.
5.1 A new agent has no history, and its parent cannot give it one
For agents that do need their own identities, a harder question remains. How do we establish that a newly created instance is the one we authorised, before it has any history of its own?
An agent may choose tools dynamically, consume untrusted material, modify its working context and create other agents to complete parts of a task. The identity infrastructure may know which application is running while knowing very little about why a particular tool call is happening.
Consider an agent asked to investigate an invoice discrepancy. It may retrieve documents, compare records and ask another agent to summarise correspondence. That second agent could be created specifically for this task.
There is no meaningful behavioural history for the new instance. It has not established normal working hours, a familiar set of collaborators or a stable pattern of resource access. Its entire lifetime might be shorter than the observation window we would normally use to establish a baseline.
That makes behavioural assurance super tough.
We may still have useful context about the application, the approved deployment, the initiating user and previous executions of similar tasks. But we should distinguish that contextual evidence from a history belonging to this particular instance.
The parent agent cannot close the gap by saying that the child is trustworthy.
It might be compromised. It might have followed instructions hidden in a document. It might have misunderstood the user’s request. It might also be perfectly legitimate while creating a child with excessive permissions.
There is a useful comparison with a human manager. A manager may recognise a person through an established relationship and confirm their employment or responsibilities through a separate channel. A parent agent’s assertion may simply be another output from the same execution chain we are trying to assess.
Even a manager’s endorsement needs authentication and limits. We should apply at least that much scrutiny to an agent.
This does not make parentage irrelevant. A verifiable delegation from an authorised parent can be valuable evidence. It tells us something about how authority reached the child. It does not automatically give the child a reputation or establish that every instruction it received was legitimate.
The underlying problem is that identity, provenance and reputation are different properties.
An agent can have a strongly established identity from its first moment of execution. It can also have clear provenance. Neither requires us to invent a behavioural history it does not possess.
5.2 Agentic impersonation makes the distinction concrete
This gives us a way to describe agent or agentic impersonation. An attacker could present a rogue agent as an approved one, copy its name and configuration, or claim that it was spawned by a trusted parent. None of those claims should be enough to establish its identity.
For an agent with its own identity, validation means connecting the caller to an independently verifiable creation record and requiring proof that it controls the key bound to that instance. We then need to check that its credentials came from an accepted issuer, remain valid and apply to the intended service. Its authority to perform the requested action needs a separate check.
For an internal agent without a distinct identity, the receiving system should make its decision using the authenticated application and verified task context. An agent’s claimed name should not create authority that the architecture never intended it to have.
An impersonator may fail these checks. A compromised legitimate agent may pass every one of them. We need to establish both who is making the request and whether the available authority permits the action.
6. How I would establish an agent’s identity when it needs one
The following is an architectural proposal built from existing security mechanisms, rather than a claim that one standard already solves the whole problem.
6.1 Define which agent we are identifying
The first requirement is to decide whether the agent needs a distinct security identity, an execution identifier for attribution, or both.
Where a distinct identity is needed, we should distinguish the application, its deployment or version, the running instance and the task context. Policy and audit records need to preserve the differences that matter.
A finance assistant deployed across the organisation may be one logical application. Two simultaneous executions investigating different invoices are separate instances. The tasks may involve different users, records and permissions.
A shared application identity alone may struggle to express those differences. Giving each execution a fresh identifier without linking it to an accountable application would lose useful context too.
The identity model needs both continuity and separation, at the boundaries the architecture actually enforces.
6.2 Record its creation outside the parent’s control
The second requirement is an independently verifiable creation record.
A trusted orchestration or identity service could record that an approved application instance was created under a particular policy, for a particular task, with an accountable owner. Where the instance receives credentials, the record could bind its identifier to a public key, an approved configuration and the request that caused its creation.
The parent can request creation. The control plane should decide whether that creation is permitted and what authority the child receives.
This moves the initial decision towards infrastructure and policy the organisation has chosen to trust. It also makes the creation event reviewable.
A signed record is only useful when we trust the issuer and understand what it checked. Signing a parent’s unverified statement would preserve the original uncertainty.
6.3 Bind the instance to a key it can prove it controls
The third requirement is proof that the caller controls the key bound to that instance.
The human authentication factors give us a useful starting point, although the analogy has limits. An agent’s knowledge can be copied with its memory or configuration. It has no human biometric, and a model fingerprint should not be treated as an equivalent.
I would therefore put the initial emphasis on proving control of a cryptographic key bound to an authorised instance, supported by independently verified creation and runtime evidence. Those supporting checks strengthen the identity decision, but we should avoid labelling them as human-style MFA without examining their independence and security properties.
A fresh cryptographic challenge can establish possession of a private key. A certificate or token can bind the corresponding public key to the identity recognised by the issuer.
Where possible, key access should be isolated from the model and its conversational context. Putting secrets in a prompt or memory store makes them part of the material an agent processes, with all the exposure that entails.
Sender-constrained credentials can also limit what an attacker gains from stealing a token alone. OAuth DPoP is one mechanism for binding token use to a key. DPoP is not itself client authentication, and it cannot stop an attacker who can make the legitimate execution environment use that key. RFC 9449 describes both the mechanism and its limits.
This matters when agents are cloned.
Copying an agent’s prompt, memory and tools should not automatically copy its authority. Separate executions that need distinct security identities should receive separate instance bindings through an authorised creation process. If they share an unrestricted key, distinguishing them becomes much harder.
6.4 Verify the environment, and be clear about the limits
The fourth requirement is evidence about the environment in which the agent is running.
Remote attestation can support claims about measured properties of an execution environment. The IETF’s RATS architecture separates the attester producing evidence, the verifier appraising it and the relying party deciding how to use the result. RFC 9334 provides the architectural model.
That separation is useful for agents. The agent’s own narrative about its configuration should not be the sole basis for trusting that configuration.
Depending on the platform, evidence might support claims about the runtime, software measurements or key binding. Freshness matters, as does the relationship between the evidence and the actual caller.
The limits need to remain visible. Proving that approved software is running does not prove that its current reasoning is correct. Measuring a runtime does not automatically measure every remote model, retrieved document or subsequent change in working context.
For an agent using a third-party model service, some properties may remain dependent on provider assertions and contractual controls. We should record those dependencies clearly.
6.5 Make delegation explicit and constrain it at every step
The fifth requirement is explicit, constrained delegation.
Every protected action should preserve the distinction between the principal whose authority is being exercised and the application or agent currently exercising it.
A child asked to summarise an invoice should not receive a copy of its parent’s unrestricted credential. It should receive authority appropriate to the records and operation it needs, or operate through an application that enforces those limits.
OAuth token exchange already provides mechanisms for representing subjects and actors. Its actor claims can also record delegation history. That history has specific semantics and does not automatically authorise each participant or implement every restriction an agent workflow needs. RFC 8693 is a useful building block.
An agent architecture still needs policy for whether delegation is permitted, which resources it covers, how long it lasts and whether further delegation is allowed.
The parent’s authority should establish an upper bound. The task and the receiving system should narrow it further.
6.6 Approve the actual action the agent is about to take
The sixth requirement is to bind high-impact approval to the actual action.
“Act on my behalf” is a very broad grant. A user asking an agent to investigate a payment has not necessarily authorised it to change the beneficiary or send money.
For consequential actions, I would want the approval to identify the relevant transaction details, the permitted operation and its expiry. The enforcing service should check that the requested action matches that approval.
This check belongs outside the model’s reasoning process. The model can propose the action and explain it. A separate control should decide whether the evidence and policy permit execution.
A generic possession proof does not necessarily cover the request body or all the business details we care about. Binding approval to a payment amount or destination requires an explicit mechanism and verification of those fields.
6.7 Keep enforcing policy after the identity check passes
The seventh requirement is continued enforcement after initial attestation.
A legitimate agent may encounter malicious instructions in a retrieved document or tool result. Its identity can remain authentic while its actions move outside the user’s intended task.
OWASP describes excessive agency as a risk arising from excessive functionality, permissions or autonomy, including actions triggered through compromised peer agents and prompt injection. Its guidance on excessive agency is directly relevant here.
Attestation therefore needs to feed an ongoing decision process. Tool access, data movement, delegation and sensitive operations should remain subject to policy.
Behavioural signals can help identify deviations from a task or peer group, even before an individual baseline exists. They should be treated as contextual evidence with uncertainty attached. A new agent should receive bounded access appropriate to what is known about it.
These controls matter whether authority is enforced through a distinct agent identity or through the application hosting it.
7. An agent’s memory is a poor identity document
We should also be careful about asking an agent questions to establish its identity.
A system prompt, a remembered conversation or knowledge of a previous task may feel like the machine equivalent of private human knowledge. Those things can be copied, exposed or fabricated.
The human comparison is useful here. A contextual question may provide supporting evidence because of the relationship between a person and their lived experience. Even then, we have to consider who else knows the answer. For an agent, transferring that experience may be as straightforward as copying a memory store.
A model’s writing style is a poor identity anchor too. It can vary legitimately and be imitated. A convincing explanation of who an agent is does not establish a binding between that explanation and an authorised execution.
Private task context may help assess continuity. Cryptographic evidence and independently established creation records provide a stronger basis for identity.
Build provenance adds another useful layer. It can help verify how an artefact was produced and whether that matches policy. SLSA describes verification against trusted build identities and expected provenance. Its artefact verification guidance supplies a practical foundation.
That evidence still needs to be interpreted within its scope. It does not establish that the agent’s current input is safe or that an authorised workflow has reached the right conclusion.
8. What this would look like in a real workflow
Putting these ideas together, the invoice investigation becomes easier to reason about.
The employee authenticates and requests an investigation. An approved orchestration service creates an execution bound to that task. The application limits retrieval to the relevant invoice and supporting records.
An internal agent summarises information already supplied to it. It needs an execution identifier for attribution, but no separate credentials.
Another agent needs to retrieve correspondence directly from a protected service. In this architecture, that crosses a boundary where independent permissions and revocation are useful. The control plane checks whether the delegation is allowed and issues a distinct identity with narrowly scoped access. This agent receives no payment authority.
Each resource server checks the authenticated caller and applicable permissions. The audit trail preserves the initiating user, the relevant application or agent, and the task context.
If the investigation concludes that a payment needs changing, that becomes a separate approval decision bound to the proposed change.
An instruction embedded in an invoice cannot grant payment rights. A parent’s request cannot bypass the child’s permission boundary. A valid credential cannot turn a read-only task into an authorised transfer.
Those properties depend on enforcement throughout the workflow. They cannot be created by putting a well-written policy into the agent’s prompt.
Now introduce an impersonator. It copies the independently authenticated agent’s name, claims to be part of the investigation and requests the same correspondence. The receiving service needs evidence connecting that caller to an authorised instance. A matching name or plausible task description contributes little if the caller cannot prove possession of the bound key and present valid credentials for that service.
For the internal summarisation agent, the control sits elsewhere. Its name is not an authentication claim. The hosting application must validate the task context and enforce any proposed action before allowing it to affect another system.
The lifecycle needs the same attention. We need to know what happens when the task completes, a parent is compromised or a human withdraws approval.
Revoking a parent credential will not necessarily invalidate credentials already issued to children. The architecture needs explicit handling for descendant permissions, active sessions and downstream grants. Short expiry limits exposure, while more immediate controls may be needed for sensitive operations.
Restart and recovery should go through trusted infrastructure too. An agent that has lost its key should not regain access by recalling facts about its previous execution.
Across organisations, the problem becomes one of federation as well. A supplier’s signed assertion has value only if the receiving organisation trusts the issuer, understands the assurance behind it and accepts the relevant delegation. An unfamiliar agent’s signature cannot establish those relationships by itself.
9. Where this leaves us
The common thread across humans, NHIs and agents is accountable evidence.
For humans, something we know, something we have and something we are give us established ways to authenticate. Deeper contextual understanding could make recovery decisions more informed and less dependent on information an attacker can research. Its value needs to be measured alongside stronger recovery evidence and the privacy implications of collecting it.
For conventional NHIs, attestation can connect credentials to an approved workload, execution environment and owner.
For agents, the first decision is where authority should sit. Some need independently verifiable identities. Others can operate within an application that authenticates, constrains access and preserves attribution on their behalf.
Where agents do have their own identities, we need to carry the connection between identity and authority through creation, delegation and action. Their short lifetimes make a personal behavioural history unreliable as an initial foundation. Their autonomy makes broad inherited authority dangerous.
Agentic impersonation makes the identity question particularly concrete. We need to validate that an authenticated agent is the approved instance it claims to be, while recognising that even a correctly identified agent can misuse its access or be induced to act outside its task.
I think the opportunity for identity security is to make these relationships visible and enforceable. We should be able to establish what is acting, where it came from, whose authority it is using, what that authority permits and what evidence supports the decision right now.
That gives us a practical basis for deciding when an agent needs an identity, how to validate it when it does, and how to constrain its actions in either case.