Because packaging standardisation does not define who authorises tool use or how secrets are scoped at runtime. That leaves the highest-risk decisions to client implementations, which are rarely uniform. The result is fragmented governance, inconsistent audit evidence, and a larger attack surface for compromised credentials and overbroad tool access.
Why This Matters for Security Teams
Agent plugin standards can make tool packaging look consistent while leaving the hardest security questions unresolved: who is allowed to invoke a tool, what data can be passed into it, and what secrets it can reach at runtime. That gap matters because agentic systems are goal-driven and can chain actions in ways static IAM never anticipated. The relevant risk is not the manifest format itself, but the runtime authority granted to the agent.
In practice, this is where teams lose control. A plugin can be “approved” on paper while the client still hands over broad API access, long-lived tokens, or unreviewed context. NHI Management Group research shows 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. That pattern is consistent with what the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both imply: governance must follow actual runtime behaviour, not just integration packaging. In practice, many security teams encounter plugin abuse only after overbroad credentials have already been issued and reused.
How It Works in Practice
Most plugin standards define how tools are described, discovered, or invoked, but they rarely define the security primitives that determine whether an autonomous agent should be trusted to use them. For NHI governance, the important shift is from “is this plugin known?” to “is this specific action safe right now?” That requires runtime authorisation, short-lived credentials, and workload identity rather than static, reusable secrets.
Current guidance suggests treating the agent itself as a workload with cryptographic identity, then evaluating every tool call against policy at request time. That can include SPIFFE or OIDC-based workload identity, ephemeral tokens issued just-in-time, and policy-as-code checks for purpose, scope, destination, and data sensitivity. The question is not whether a plugin exists in a registry, but whether the agent’s current task justifies access to that tool and its underlying secret.
- Issue per-task credentials with narrow scope and short TTLs.
- Bind tool access to the agent workload identity, not a shared service account.
- Log the decision context: intent, input data class, policy result, and secret scope.
- Revoke access automatically when the task completes or the session changes.
That model aligns with the CSA MAESTRO agentic AI threat modeling framework and the practical controls reflected in NHIMG research such as OWASP NHI Top 10, especially where secrets sprawl and privilege inflation are the real issue. These controls tend to break down when the client application reuses a shared token cache across agents because one compromised session can inherit another agent’s authority.
Common Variations and Edge Cases
Tighter plugin controls often increase integration overhead, requiring organisations to balance developer convenience against runtime containment. That tradeoff is especially visible in multi-agent pipelines, where one agent may call another, or where a tool broker mediates access on behalf of several clients. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: approval at install time is not enough for autonomous execution.
Edge cases usually appear where trust boundaries are blurry. A plugin may be harmless for read-only retrieval but dangerous when the same client can pass it live credentials, production data, or unrestricted prompts. Similarly, a “safe” internal tool can become a lateral movement path if the agent can compose it with other tools. NHIMG’s reporting on the Top 10 NHI Issues is a useful reminder that excessive privilege, poor rotation, and weak offboarding remain common failure modes.
For teams setting policy, the practical rule is simple: if the plugin standard does not define runtime authority, secret scoping, and revocation, then it does not resolve NHI risk by itself. It only reduces format drift while leaving operational trust decisions to each client implementation.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agent tool use and runtime trust are central to this question. |
| CSA MAESTRO | TA-02 | MAESTRO addresses agentic tool abuse and trust boundaries. |
| NIST AI RMF | GOVERN | Governance is needed when plugin standards leave runtime authority undefined. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credential scope and rotation directly reduce plugin-driven NHI exposure. |
| NIST Zero Trust (SP 800-207) | PR.AC-5 | Zero Trust supports request-time decisions for dynamic agent tool access. |
Evaluate each tool call continuously and deny access unless policy and context both match.
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
