Different AI use cases create activity in different places. Some traffic passes through an LLM gateway, while other actions happen directly on endpoints or inside local clients. A single control point can miss tool calls, session context, or device-level behaviour. Mature governance combines gateway logging, endpoint audit hooks, and catalog policy so teams can see the full path of AI activity.
Why This Matters for Security Teams
ai governance fails when teams assume there is one place to inspect, one log to trust, and one policy engine that sees everything. That model breaks quickly because AI activity can start in a browser, continue through an LLM gateway, invoke tools from a local client, and persist state on the endpoint. Security teams need multiple control points because each layer observes different evidence of intent, access, and data movement.
NHIMG guidance on the Top 10 NHI Issues and the NIST AI Risk Management Framework both point to the same operational reality: governance has to follow the workload, not just the perimeter. If secrets, tool permissions, and audit evidence are split across systems, a single control point becomes a blind spot rather than a safeguard. In practice, many security teams encounter uncontrolled AI tool use only after data has already left the approved path.
The risk is especially acute for non-human identities because attackers target the credentials and session artifacts that let AI systems act autonomously. NHIMG research on LLMjacking shows how fast exposed credentials can be abused, which is why control design must include the gateway, the endpoint, and the identity layer together.
How It Works in Practice
Effective AI governance uses layered controls, each answering a different question. The gateway sees model prompts, response filters, and sanctioned API traffic. Endpoint controls see local clients, browser extensions, desktop agents, and tool execution that never touches a central proxy. A catalog or policy layer defines which models, plugins, datasets, and agent workflows are allowed in the first place. Together, those layers create coverage for discovery, approval, execution, and review.
For AI agents and other autonomous workloads, that layered model matters even more. A static IAM rule cannot reliably describe what an agent will do next, so current guidance suggests pairing policy enforcement with runtime context. That can mean intent-based authorisation, just-in-time credential issuance, and short-lived workload identity rather than standing credentials. Where possible, teams should verify the agent as a workload, not merely as a user, using cryptographic identity patterns such as SPIFFE, OIDC, or equivalent workload attestations. Real-time policy evaluation also matters because the same agent may be safe for one dataset and unsafe for another.
Practically, teams often split responsibilities like this:
- Gateway logging for prompt, completion, and model routing visibility
- Endpoint audit hooks for local action, file access, and tool invocation
- Identity and secret controls for ephemeral access, rotation, and revocation
- Catalog policy for approved models, agents, and data classifications
NHIMG’s Lifecycle Processes for Managing NHIs and the NIST AI 600-1 GenAI Profile reinforce that governance is strongest when controls are distributed across the full AI lifecycle, not concentrated at a single choke point. These controls tend to break down when local AI clients can call tools offline or when endpoint telemetry is blocked by privacy settings or unmanaged devices.
Common Variations and Edge Cases
Tighter control coverage often increases operational overhead, requiring organisations to balance visibility against latency, user friction, and policy sprawl. That tradeoff becomes obvious in environments with shadow AI, offline assistants, or highly distributed developer endpoints.
There is no universal standard for this yet, but best practice is evolving toward environment-specific control combinations. A finance team may need stronger catalog approval and model allowlisting, while an engineering team may need endpoint hooks and short-lived credentials for build agents. In regulated settings, governance evidence should be retained from multiple points so audits can reconstruct what happened even if one log source is incomplete.
One common mistake is relying on the gateway as if it were a complete control plane. If an AI feature runs inside a desktop client, an IDE plugin, or a local orchestration service, the gateway may never see the full action chain. NHIMG’s Regulatory and Audit Perspectives and the NIST AI Risk Management Framework both support a multi-evidence approach. The practical lesson is simple: when AI can act outside the gateway, policy must also exist outside the gateway.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Agentic workloads need runtime controls across gateway and endpoint paths. |
| CSA MAESTRO | AI-03 | MAESTRO addresses distributed controls for autonomous AI workflows. |
| NIST AI RMF | AI RMF fits multi-point governance across governance, map, measure, and manage. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Multiple control points reduce exposure from compromised NHI secrets and tokens. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be enforced across gateways, endpoints, and catalogs. |
Apply AI RMF to assign risk ownership and evidence collection across all AI control points.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
