Because attestation proves which process is speaking, not what it is allowed to do on behalf of a user or service. An agent can be correctly identified and still act outside its intended scope if request-level authorisation is not layered on top. The control problem is therefore provenance plus authority, not provenance alone.
What attestation actually proves, and what it does not
Attested workload identity answers the provenance question: which workload, process, or runtime is presenting itself. That is useful because it gives the platform a stronger basis for trusting the caller’s origin, environment, or cryptographic proof. It does not, by itself, answer the separate question of whether that caller may act on a specific user’s behalf or invoke a particular operation.
For agents, that distinction matters because an agent can be genuine and still be too powerful. If the system treats “this is a valid workload” as equivalent to “this workload may perform this action,” then identity proof becomes an implied permission grant. That is where delegated authorisation enters: it binds an authenticated agent to an explicit scope, consent, or policy envelope.
Attestation therefore strengthens trust in the caller, while delegated authorisation constrains the caller’s authority. In practice, both are needed when an autonomous or semi-autonomous agent acts across systems, because the security decision is about provenance plus intent plus permitted action, not provenance alone.
Why delegated authorisation is the missing control layer
Delegated authorisation becomes necessary whenever an agent must do more than authenticate to a service. The agent may need to read data, create records, trigger workflows, or make changes on behalf of a user or service, and each of those actions can require different approval boundaries. A valid workload identity can establish that the request came from the expected agent, but only delegation decides which requests are legitimate in context.
This is why workload identity and delegated authority are complementary rather than interchangeable. Attestation can help you trust the environment the agent runs in, while delegation defines the operational contract for that agent’s actions. When those layers are separated cleanly, a compromised or over-eager agent is less likely to turn a valid identity into broad, undesired access.
The practical design point is to keep the agent’s identity narrow and its authority explicit. That usually means short-lived delegation, scoped tokens or claims, and request-level checks that are evaluated against the action being attempted, not just the source of the request. The safer pattern is to ask both “who is this agent?” and “what is it permitted to do right now?”
Where teams get this wrong in agentic systems
One common mistake is to let attestation serve as a proxy for consent. That shortcut is attractive because it simplifies implementation, but it collapses two separate decisions into one: verifying the caller and authorising the caller’s action. In an agentic system, that can quietly turn a verified workload into a broadly empowered actor.
Another failure mode is over-broad delegation. Teams often grant a single agent a large standing scope so that it can “just work” across workflows. That may reduce friction, but it increases blast radius when the agent is misconfigured, manipulated, or asked to do something adjacent to its intended use. This is especially important when agent identity and delegation are part of the design, because the authority model has to match the operational role.
Teams also underestimate how often an agent’s authority should change by context. A request that is safe in one workflow may be unsafe in another, even when the same workload identity is speaking. That is why request-level authorisation has to remain in the path after attestation has succeeded.
Risk and Threat Considerations
When attestation is treated as sufficient authority, a confirmed agent can still make high-impact requests outside its intended remit. The risk is not just impersonation, it is overreach, where a legitimate process is allowed to do too much because the control stack stopped at identity proof.
Failure mechanism: Attestation validates the workload’s provenance, but the platform fails to enforce action-specific scope, consent, or policy. An attacker who gains control of the agent, or a benign agent that receives a broader task than intended, can then use valid identity to perform unauthorised operations.
Impact: The result can be data exposure, unauthorised writes, privilege escalation by delegation, or lateral movement through trusted integrations. In agentic environments, that can also make misuse harder to spot because the activity appears to come from a legitimate workload.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identity proof alone does not grant action authority. |
| Recommendation — Enforce request-scoped authorization so verified agents cannot exceed delegated privileges. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Workload attestation establishes which service or agent is calling. |
| AC-3 — Access Enforcement | Delegated authorisation is the control that limits what a valid agent may do. | |
| AC-6 — Least Privilege | Agents should receive only the minimum authority needed for the delegated task. | |
| Recommendation — Authenticate workloads strongly, then layer authorization on each sensitive request. Enforce per-action authorization checks before the agent can execute privileged operations. Constrain agent permissions to the smallest scope and shortest duration possible. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles | The question hinges on verifying every action, not trusting identity alone. |
| Recommendation — Verify each request explicitly instead of treating authenticated identity as standing trust. | ||
Practitioner Guidance
What to verify: Confirm that attestation only gates trust in the caller’s identity and runtime, while a separate decision evaluates the specific action, resource, and delegated scope. If those checks are merged, the control is too coarse for agent use.
Decision rule: If an agent can change state, reach user data, or chain into another system, require request-level authorisation that is narrower than the workload’s identity proof. Treat “authenticated workload” as necessary evidence, not as permission.
What good looks like: The agent can prove who it is, but each sensitive action still depends on explicit, time-bound authority that is easy to inspect and revoke. That is the difference between a trusted process and a trusted delegate.
Practitioner takeaway: Attestation should tell you the agent is real, delegated authorisation should tell you the agent is allowed, and secure systems need both before they let an agent act.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org