They should do both: keep APIs as the execution path for predictable actions, but add an AI control layer above them to govern agent behaviour. The new problem is not replacing APIs, it is deciding how AI-initiated requests are authorised, inspected, and recorded.
Why this is no longer just an API question
Agent-driven requests should be treated as API traffic at the execution layer, because that is where the work actually happens. But the control question changes: the organisation is no longer only validating payloads and endpoints, it is deciding whether an agent may initiate, shape, chain, or repeat requests under a given policy, context, and level of authority.
That distinction matters because the same API can be safe for deterministic software and unsafe for a model that is allowed to infer next steps, choose tools, or retry actions autonomously. The control boundary moves upward, above the API, so the API becomes one enforcement point rather than the whole governance model.
What the new control layer has to govern
The new layer has to answer questions that classic API security does not fully resolve: who or what is the acting principal, what action is being attempted, what scope is justified, and what evidence is recorded for review. In practice, that means separating request creation from request execution and treating authorisation as an explicit decision per action, not a one-time login event.
It also means recognising that agent behaviour can be legitimate without being uniformly trusted. Some requests should be allowed automatically because they are predictable and low impact, while others need stronger checks because they can change data, move money, expose content, or call downstream systems. The key is not to ban autonomy, but to bound it.
- Use the API as the execution surface for bounded tasks and repeatable workflows.
- Use a policy layer to decide whether the request is allowed, whether it needs human approval, and what context must be attached.
- Log the initiating context, the policy decision, and the resulting action so the request can be attributed later.
Why authorisation and observability have to change together
If an agent can initiate requests, then approvals, denials, and post-action review must be designed for machine-speed behaviour. A control model that only checks credentials at session start will miss the real risk, because the important decision is often the action itself, not the login that preceded it.
For that reason, agent traffic should be inspected for intent, scope, and consequence, not only for schema validity or transport security. This is where organisations often discover that their existing API gateway, rate limits, and audit logs are necessary but insufficient. They protect the pipe, but not the decision to use the pipe in the first place.
Good practice is to align request authorisation with the smallest safe unit of work, then preserve enough evidence to reconstruct why the agent was allowed to act. The AI Agent Authorisation Guide is a useful reference for task-scoped access, per-action decisions, and approval gates, while the AI Agent Observability, Audit and Incident Response Guide shows what to log and how to attribute actions when something goes wrong.
Risk and Threat Considerations
Agent actions expand the attack and abuse surface because a request can be technically valid while still being operationally unsafe. The main risk is not just broken authentication at the API, but excessive authority, poor delegation boundaries, and weak traceability when an agent chains several allowed calls into an unintended outcome.
Failure mechanism: A hostile prompt, poisoned context, or over-permissive policy causes the agent to issue authorised requests that are individually permitted but collectively harmful, and the organisation cannot quickly prove which decision led to the action.
Impact: The result can be data exposure, unauthorised state change, business-flow abuse, or delayed containment because responders cannot distinguish normal automation from misbehaving agent activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Agentic AI Top 10 address 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 API Security Top 10 | API5 — Broken Function Level Authorization | Agent-initiated actions need per-action authorization at the API layer. |
| Recommendation — Enforce function-level authorization for every agent-triggered request before execution. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent actions depend on credential handling, rotation, and bounded use of secrets. |
| AU-2 — Event Logging | Agent decisions and actions need auditable logs for attribution and review. | |
| Recommendation — Manage agent credentials with lifecycle controls and rotation discipline. Log agent requests, policy decisions, and executed outcomes for traceability. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Agent actions should be continuously verified and authorised per request. |
| Recommendation — Apply per-request verification and least privilege to agent-triggered access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent actions can exceed intended authority or be misused through delegated privilege. |
| Recommendation — Limit delegated authority and validate each agent action against policy. | ||
Practitioner Guidance
What to prioritise: Define which agent actions are low-risk enough to run as ordinary API calls and which actions require a separate approval or policy decision before execution. If a request can change privileged state, touch sensitive data, or trigger downstream side effects, it needs more than standard API validation.
What to verify: Confirm that each action is attributable to a principal, a policy decision, and a bounded scope, not just to a logged-in session. If you cannot explain why the agent was allowed to act, you do not yet have a control layer, only an execution path.
Practitioner takeaway: The mature pattern is to keep APIs as the mechanism, but move trust decisions above them, where authority, context, and auditability can be controlled per action.
Related resources from NHI Mgmt Group
- When should organisations treat an AI agent as a privileged system?
- What breaks when organisations treat the DOJ rule like a privacy notice instead of an infrastructure control problem?
- When does an AI agent become a privileged access problem?
- When should organisations treat agent access as a privileged access problem?