They lose sight of the actual attack surface, which sits in the tools, connectors, and APIs that convert model output into action. A model can be safe in isolation and still drive harmful outcomes if it can reach privileged systems. Effective governance requires tracing each integration that gives the system real-world reach.
Why This Matters for Security Teams
Securing only the model creates a false sense of control because the model is not the part that changes systems. The risk is in the surrounding integrations: API tokens, tool permissions, SaaS connectors, workflow triggers, and delegated access that turn text into action. NIST’s NIST Cybersecurity Framework 2.0 emphasizes identifying assets and managing risk across the full environment, not just one component.
That matters because a safe model can still be an unsafe operator. Once an LLM or agent can call a ticketing system, read email, query production data, or push to CI/CD, the real attack surface becomes the trust chain around those actions. This is where NHI governance becomes central: access is carried by service accounts, OAuth grants, API keys, and automation credentials rather than by the model itself. The same pattern shows up in incidents such as GitHub Repo Breach — Heroku and Travis CI OAuth Tokens, where delegated integrations created the blast radius.
NHI Mgmt Group research shows the pattern is widespread: 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges, which means integration sprawl often outruns governance. In practice, many security teams discover this only after a model has already triggered a privileged workflow, rather than through intentional design review.
How It Works in Practice
The right control boundary is the integration layer, not the model endpoint. Security teams should inventory every connector, tool call, webhook, and downstream API that the system can reach, then map each one to an owner, purpose, privilege level, and expiry. That includes service accounts used by orchestration code, OAuth scopes granted to apps, and CI/CD or data-platform credentials that an agent can invoke indirectly. Current guidance suggests treating these as NHIs with their own lifecycle, not as incidental implementation details.
Practical governance starts with three questions: what can this integration touch, what authenticates it, and how is it revoked. For agentic systems, runtime policy is more effective than static allowlists because behaviour is dynamic. A model may ask for data extraction one minute and deployment access the next, so pre-defined role sets often lag behind actual intent. Policy-as-code engines, workload identity, and just-in-time credential issuance are better aligned with this reality than long-lived shared secrets.
- Trace every tool, connector, and API to the privilege it inherits.
- Replace broad standing credentials with short-lived, task-scoped access where possible.
- Use workload identity and strong token binding so the system proves what it is, not just what secret it knows.
- Review integration logs for action paths, not just model prompts and outputs.
Incidents like the Klue OAuth Supply Chain Breach and the Vercel Context.ai OAuth Supply Chain Breach show how trusted integrations can become the entry point even when the model layer itself is not the primary weakness. These controls tend to break down when teams embed AI into legacy automation stacks with shared service accounts and no clean revocation path, because privileges become impossible to separate from normal business operations.
Common Variations and Edge Cases
Tighter integration control often increases operational overhead, so organisations have to balance containment against delivery speed. That tradeoff becomes sharper in environments with many third-party plugins, rapid experimentation, or citizen-developer workflows where connectors are added faster than they can be reviewed.
There is no universal standard for this yet, but current guidance suggests different handling based on risk. High-impact integrations such as production deployers, finance systems, and customer-data stores should receive the strongest controls: explicit approval, JIT access, and continuous logging. Lower-risk tools, such as read-only knowledge search, may tolerate broader access if the data they expose is already public or sanitized. The key is to classify by action, not by whether the tool is “AI.”
Another common edge case is the illusion of safety from sandboxing the model. Sandboxes help, but they do not solve credential reuse, overbroad OAuth consent, or lateral movement through downstream systems. The same is true for agent frameworks that hide the integration complexity behind abstractions. Security review still has to follow the call chain from prompt to tool to privileged action, especially in workflows that mix human approval with autonomous execution.
For organisations building governance programs, NHI Mgmt Group recommends treating every integration as an identity-bearing component and using Ultimate Guide to Non-Human Identities as the baseline reference for lifecycle and visibility expectations. That approach is more durable than model-only hardening because it targets the systems that actually move data and make changes.
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 | A05 | Covers tool abuse and unsafe agent actions through integrations. |
| CSA MAESTRO | TAI-02 | Focuses on agent toolchains and external system reach. |
| NIST AI RMF | GOVERN | Requires governance over downstream impacts of AI-enabled decisions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Integration credentials are NHIs and need lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central when models can invoke privileged tools. |
Assign accountable owners for every AI integration and review its operational risk.
