How should organisations secure AI agent transactions when agents can act with delegated authority?

Why This Matters for Security Teams

When an AI agent is allowed to book travel, trigger payments, open tickets, or call internal APIs, the transaction is no longer a simple application event. It becomes a governed identity event that can move money, change records, or expose data with the agent acting under delegated authority. That changes the security question from “is the app authenticated?” to “did the right agent, for the right intent, within the right scope, execute this action?” The OWASP Agentic AI Top 10 and NHIMG’s OWASP NHI Top 10 both point to the same operational reality: agents can chain tools, reuse delegated privileges, and make decisions faster than human approval workflows can reliably intervene.

Static IAM assumptions break quickly here because agents do not follow a fixed, human-shaped access pattern. A calendar agent may suddenly need expense approval, a procurement agent may need supplier records, and a coding agent may invoke deployment tooling after interpreting a prompt. In practice, many security teams encounter abuse only after an agent has already executed a valid but unintended action, rather than through intentional testing of the delegated path.

How It Works in Practice

The control objective is to make each agent transaction verifiable, bounded, and short-lived. Security teams should bind four elements together at request time: the agent identity, the declared intent, the delegated credential or payment token, and the user or policy consent that authorised it. That is consistent with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize runtime context and accountable system behaviour rather than static trust labels.

In implementation terms, best practice is evolving toward workload identity plus just-in-time delegation. Use cryptographic workload identity for the agent, such as SPIFFE or OIDC-backed service identity, so the platform can prove what the agent is. Then issue ephemeral credentials per task, with tight TTLs and automatic revocation when the task completes. For higher-risk actions, require policy-as-code decisions at runtime, using context such as destination, amount, resource type, risk score, and whether a human approved the scope. NHIMG’s OWASP Agentic Applications Top 10 highlights why this matters: an agent that can explore tools dynamically should not inherit broad standing privilege.

• Issue delegated credentials only for the specific transaction, not for the whole session.
• Bind approvals to intent, amount, target system, and expiry time.
• Log the full chain: prompt, policy decision, credential minting, and action result.
• Revoke or quarantine the delegation when the task changes scope.

The practical goal is to convert “agent may act” into “agent may act only for this approved operation, now, with this proof.” These controls tend to break down when legacy applications cannot evaluate policy at request time because they only support coarse session tokens and broad, long-lived service accounts.

Common Variations and Edge Cases

Tighter transaction binding often increases integration overhead, requiring organisations to balance assurance against latency, developer friction, and approval bottlenecks. That tradeoff matters most in high-volume agent workflows where a human cannot review every step, so current guidance suggests using step-up controls only for high-risk actions rather than every call.

One common edge case is multi-agent choreography. If one agent plans, another executes, and a third reconciles payments, the organisation needs transaction lineage across all three identities, not just the last service call. Another is consent drift, where a user approves one action and the agent expands the task after new context appears. The safest pattern is to re-evaluate policy whenever scope, target, or value changes.

Another failure mode is over-reliance on long-lived secrets in vaults or environment variables. NHIMG research on The State of Secrets in AppSec shows why secret sprawl is already hard to contain, and agentic systems amplify that risk because compromise can happen at machine speed. Where fraud controls are involved, payment credentials should be tokenized and constrained to merchant, amount, and expiry. For implementation patterns, the LLMjacking research is a useful reminder that exposed credentials are often exploited within minutes, not days.

Related resources from NHI Mgmt Group

• How can organisations prevent AI agents from becoming overprivileged?
• When should organisations treat an AI agent as a privileged system?
• How can organisations govern AI agents that use service accounts and tokens?
• What breaks when organisations do not manage AI agent credentials across their full lifecycle?