Because they can execute delegated tasks at machine speed and across many more requests than a person would. That means the application is no longer just presenting information, it is authorising actions. Teams must decide which flows are human-only, which are agent-enabled, and which need explicit machine credentials.
Why AI agents change the access model
AI agents are not just faster users. They can be instructed once and then carry out many actions, often without a person reviewing each step. That changes the core security question from “Can this person view the page?” to “What is this principal allowed to do, under what policy, and with what blast radius when the action is automated?”
That shift matters because an agent can cross from read-only assistance into state-changing behaviour very quickly. A system that was safe when every transaction was initiated and confirmed by a human may become unsafe when the same workflow can be repeated, chained, or adapted by software.
AI agents also blur the boundary between identity, delegation, and execution. Once the application accepts an agent as a valid actor, it has to decide whether the request is made on behalf of a user, under a machine credential, or through some limited delegated permission set. The right model depends on the action, not just on who started the conversation. AI Agent Authorisation Guide
What changes in transaction handling
Transactions need to be evaluated as actions with consequences, not only as requests with inputs. For an agent, a transaction can be part of a sequence: gather data, compare options, call a tool, submit a change, then continue with the next step. That means the application should distinguish between informational actions, low-risk operational actions, and high-impact transactions that require tighter approval or stronger proof of intent.
This is where per-action policy becomes more important than session-wide trust. If the same agent can check inventory, create records, and approve payments, then the control problem is no longer about “is the session authenticated?” but “is this exact transaction authorised?” Practitioners should expect more granular decisions, shorter-lived permissions, and clearer separation between read, draft, and commit stages. Zero Trust for AI Agents
Applications also need to think about transaction integrity. An agent may retry, parallelise, or reinterpret a workflow in ways that a human would not. Good design therefore includes idempotency, explicit confirmation points for irreversible steps, and controls that prevent an agent from turning a single instruction into multiple equivalent side effects. AI Agent Observability, Audit and Incident Response Guide
How to decide what the agent may do
The practical design task is to classify flows by authority. Human-only flows should remain human-only, especially where the consequence is external, irreversible, or financially sensitive. Agent-enabled flows should be limited to actions that can be bounded, observed, and rolled back. The remaining category is explicit machine credentials, which are appropriate only when the agent truly needs durable access and the token scope is narrow enough to keep the risk contained.
That classification is easier when teams document the minimum authority needed for each workflow. A useful rule is to start with the transaction, then decide whether the agent needs draft access, submission access, or full execution rights. The narrower the right, the more defensible the design. Where an agent acts for a user, the application should preserve that chain of delegation so downstream systems can see who approved the authority and what was actually granted. Agentic AI Identity Guide
For teams building or reviewing these flows, the best signal of maturity is not whether the agent can act, but whether every material action has a clear policy boundary and an attributable audit trail. That is what keeps automation useful without turning it into unbounded authority. AI Agent Observability, Audit and Incident Response Guide
Risk and Threat Considerations
AI agents increase exposure because a compromised prompt, tool call, or delegated token can produce many actions very quickly. The main danger is not just unauthorised access, but scale: one weak approval path can become repeated misuse, excessive transactions, or abuse of a trusted workflow before a human notices.
Failure mechanism: An attacker, or a flawed agent instruction, can exploit overbroad authority, token reuse, or weak action scoping to turn a legitimate delegated workflow into unauthorised state change, data movement, or transaction submission.
Impact: The result can include financial loss, data corruption, privilege escalation, fraudulent requests, or large-scale operational damage, especially where the application treats the agent as trustworthy once the session is established.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents change transaction handling through delegated authority and overbroad privileges. |
| ASI02 — Tool Misuse | Agents can chain tools into unintended state-changing workflows. | |
| Recommendation — Scope agent permissions per action and require approval for high-impact transactions. Constrain tool access so agents can only invoke approved actions for each workflow. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Machine and agent credentials matter when software authenticates to services. |
| AC-6 — Least Privilege | Agent-driven transactions need narrowly scoped authority to limit blast radius. | |
| Recommendation — Use service authentication controls to bind agent access to approved service identities. Restrict agent permissions to the minimum access needed for each transaction. | ||
Practitioner Guidance
What to prioritise: Classify every agent-facing workflow by blast radius first. If an action can spend money, change records, or trigger external effects, do not let it inherit the same permissions as a read-only assistant.
What to verify: Confirm that each agent transaction has a clear policy decision point, a narrow scope, and a logged reason for approval. If you cannot explain why the agent needed that authority, the permission set is too broad.
Decision rule: If the flow is irreversible or externally visible, require explicit approval or a constrained machine credential. If the flow is reversible and low impact, keep the permission short-lived and tightly bounded.
Practitioner takeaway: The key design change is to stop treating the agent as a user session and start treating it as a delegated actor whose authority must be scoped per action, not per login.
Related resources from NHI Mgmt Group
- Why do AI agents create a different access-risk profile than traditional applications?
- When is it crucial to implement least-privilege access for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?