They fail at execution time. Gateways can inspect requests and directories can authenticate a principal, but neither owns what the agent does after access is granted. If the control must block, attribute, or meter an action while it is happening, governance has to move into the workload path rather than remain outside it.
Why gateways and directories stop short of agent governance
API gateways and directories are useful control points, but they govern entry, not execution. A gateway can validate traffic before it enters a system, and a directory can establish who or what is calling, yet neither controls the agent’s later decisions, tool use, data handling, or side effects once the request is accepted. That is the practical gap this question is really about.
For AI agents, that gap matters because the highest-risk action is often the one taken after authentication has already succeeded. If the policy decision is only made at the front door, the agent can still overstep inside the workload path, especially when it chains tools, follows dynamic instructions, or acts across multiple systems under one session.
That is why AI-agent governance has to be treated as an execution problem as much as an access problem. NHIMG’s AI Agent Authorisation Guide is relevant here because the control point has to move to per-action decisions, not stop at initial login or API entry.
Where the control boundary breaks in real deployments
The failure is structural. Gateways sit in front of services, so they are best at request screening, token checking, rate limits, and coarse policy. Directories answer questions about principal identity, registration, and authentication state. Neither is naturally positioned to decide whether a specific tool call, database write, file export, or external API invocation should be allowed at that instant.
That separation becomes visible when an agent is permitted to act on behalf of a user, but the actual work happens through downstream credentials, embedded tool permissions, or delegated access. The front-end control may be correct while the execution path is still too broad, too durable, or too poorly attributed. NHIMG’s Agentic AI Identity Guide is useful because it frames identity, delegation, registration, and retirement as lifecycle issues, not just authentication events.
Practically, this means a gateway can say “yes” to a request that later becomes “too much” after the agent has context, memory, and tool access. The directory knows the principal, but not the full blast radius of the action. Once the workload begins to execute, governance has to follow the action path, not remain attached to the original connection.
NHIMG’s Zero Trust for AI Agents captures the architectural implication well: verify the principal and request continuously, then remove standing privilege so access stays bounded at the point of use.
What governance has to move into the workload path
Execution-time governance means the control is close enough to the agent’s actual act to block, slow, attribute, or meter it before damage is done. That usually includes per-action authorisation, just-in-time privilege, observable tool calls, and event-level audit trails. If the agent can invoke tools, mutate records, or trigger payments, the policy must be enforced where those operations occur.
It also means the environment must be able to distinguish between a permitted identity and a permitted action. An authenticated agent is not automatically authorised for every tool, dataset, or downstream service it can technically reach. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is relevant because attribution and kill-switch design only work when actions are logged and stoppable while they are still in flight.
In practice, the better pattern is to treat the gateway and directory as supporting controls, then place the real decision point beside the workload, tool broker, or enforcement layer that can see the action in context. If the control cannot stop the operation, it is not governing the operation.
Risk and Threat Considerations
The main risk is false confidence. Organisations often assume that because an agent authenticated successfully, its subsequent behaviour is already governed. That assumption fails when the agent can reuse standing access, overreach through delegated permissions, or chain one accepted request into a broader harmful sequence.
Failure mechanism: A gateway or directory authenticates the principal, but the workload path still allows the agent to invoke tools, move data, or trigger side effects beyond the intended scope. The resulting gap enables overprivilege, poor attribution, and delayed containment.
Impact: An attacker, or even a misaligned agent, can turn a valid session into unauthorized action, data exposure, or destructive changes before any front-door control notices the abuse.
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 and OWASP Non-Human Identity 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 Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance hinges on controlling privileged actions after authentication. |
| Recommendation — Enforce per-action authorization to prevent agents from reusing broad access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent-to-service execution depends on authenticating non-human principals to downstream systems. |
| AC-6 — Least Privilege | The gap is excess authority after entry, so privilege must be minimized at execution time. | |
| Recommendation — Authenticate each workload or agent at the service boundary before action is allowed. Restrict agent permissions to the minimum needed for the current task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The subject is about continuous verification and enforcing policy close to the action path. |
| Recommendation — Apply continuous verification and policy enforcement at the point of use. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI agents are non-human principals that can be granted more authority than their task requires. |
| Recommendation — Audit agent permissions and remove standing privilege that exceeds task scope. | ||
Practitioner Guidance
What to prioritise: Place enforcement where the action is executed, not where the request first arrives. For AI agents, the first question is whether the policy engine can see the exact tool call, resource, or transaction that matters.
What to verify: Confirm that every high-impact action has an enforceable policy decision, a bounded privilege scope, and an attributable audit record. If the directory or gateway cannot prove those three things, they are not sufficient as the primary governance layer.
Decision rule: If the control must block or approve an action after authentication has already succeeded, treat the gateway and directory as upstream support only and move governance into the workload path.
Practitioner takeaway: The question is not whether gateways and directories are useful, but whether they can govern the moment of execution. For AI agents, that moment is where security meaningfully changes, so that is where control must live.