How should security teams govern agents that can describe their own architecture?

Why This Matters for Security Teams

Agents that can describe their own architecture are often treated as if documentation equals control. That is a mistake. A self-generated diagram may be useful evidence, but it does not prove the agent is limited to approved tools, current permissions, or compliant data paths. Governance has to follow the authoritative state, not the agent’s narrative. This is especially important because OWASP Agentic Applications Top 10 and OWASP Agentic AI Top 10 both reflect the reality that autonomous systems can chain actions, call tools, and widen their blast radius faster than traditional review cycles. NIST’s NIST AI Risk Management Framework is useful here because it pushes teams toward governable, testable controls rather than trust in model output.

NHIMG research shows the broader NHI problem is already severe: 97% of NHIs carry excessive privileges, which broadens the attack surface and makes overreliance on agent self-reporting especially dangerous. In practice, many security teams encounter the mismatch only after an agent has already been over-entitled, rather than through intentional control design.

How It Works in Practice

Security teams should govern these agents as autonomous workloads with workload identity, not as fixed users with static roles. The practical model is to bind the agent to a cryptographic workload identity, issue JIT credentials per task, and evaluate access at request time using context such as task purpose, target system, data sensitivity, and current risk posture. This is where static RBAC fails: an agent’s behavior is goal-driven and dynamic, so a pre-defined role often grants either too much access or too little to complete the task safely.

Current guidance suggests an intent-based authorisation pattern: the agent declares what it wants to do, policy evaluates whether that action is allowed now, and only then are short-lived tokens or secrets released. That aligns well with policy-as-code approaches and with the governance direction in the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework. For security teams, the operational checks are straightforward:

• Use workload identity, not shared service accounts, so the agent can be uniquely attested.
• Issue ephemeral secrets with tight TTLs and revoke them automatically after the task completes.
• Compare the agent’s self-described architecture against CMDB, IAM, and secret inventory records.
• Require real-time policy evaluation before tool calls, data export, or lateral access.
• Log every tool invocation and entitlement change for review and rollback.

That matters because the NHI lifecycle guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues both point to the same operational truth: inventory, rotation, and offboarding are controls, not paperwork. These controls tend to break down when agents are allowed to self-register tools in fast-moving CI/CD pipelines because the approved state changes faster than review and revocation processes.

Common Variations and Edge Cases

Tighter runtime policy enforcement often increases engineering overhead, requiring organisations to balance faster agent execution against stronger containment. That tradeoff is real, especially in environments where agents must call many services or operate across multiple tenants. Best practice is evolving, and there is no universal standard for when an agent should be allowed to explain its own architecture versus when that explanation must be treated as untrusted telemetry.

In regulated or high-risk environments, the safer pattern is to treat the self-generated diagram as one signal among several, then cross-check it with IAM records, secret manager state, and runtime logs. In lower-risk internal use cases, teams may accept broader autonomy, but they still need revocation paths and periodic validation. The governance logic in NIST Cybersecurity Framework 2.0 and the agentic risk framing in OWASP NHI Top 10 support that layered approach: identify, protect, detect, respond, and recover around the agent’s actual behavior, not its self-description.

One important edge case is delegation chains. If an agent can spawn sub-agents or delegate tasks through MCP-connected tools, the visible architecture may lag behind the real authority graph. Another is third-party SaaS integration, where tokens can remain live long after the agent believes a connection is closed. In practice, these risks become obvious only after the agent has already acted with broader access than intended.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?