The clearest signs are a missing AI inventory, no per-agent identity, broad inherited permissions, and no traceability for tool calls or sub-agent activity. If the platform only reports on infrastructure resources or model endpoints, it is not seeing the layer where agent risk accumulates. That is a visibility failure, not a tuning problem.
What it means when an AI posture programme is only measuring the platform
An AI posture programme is not really governing agents when it can describe the environment but not the actor. If the reporting stops at cloud resources, model endpoints, or general AI inventory, yet cannot tell you which agent acted, under what identity, or with what authority, then the programme is observing infrastructure health, not governing autonomous behaviour.
That distinction matters because agent risk accumulates in delegated access, tool use, and cross-action persistence. A programme can look mature on paper while still missing the layer where decisions become execution.
Two practical signs usually appear together: the inventory is incomplete at the agent level, and the control model never binds permissions to a specific agent identity or task scope. When those are missing, every downstream control becomes weaker because it has no stable subject to govern.
Why identity, authority, and traceability are the real test
The strongest indicator of governance failure is that the programme cannot answer basic questions about who or what made a request. An AI Agent Authorisation Guide is useful here because it frames the core control problem as task-scoped access, per-action decisions, and approval gates rather than generic policy language. If those controls are absent, the programme is not governing agent behaviour, only hoping the underlying platform remains safe.
Per-agent identity is the dividing line between posture and governance. Without it, permissions are inherited from a shared application, service account, or platform role, which means the programme cannot distinguish one agent’s authority from another’s. That makes least privilege, revocation, and accountability difficult to prove in practice.
Traceability is the other hard test. If tool calls, delegated actions, or sub-agent activity cannot be reconstructed after the fact, the programme has no defensible audit trail. An AI Agent Observability, Audit and Incident Response Guide helps because it treats attribution, logging, and response evidence as first-class requirements rather than optional telemetry.
What the missing controls usually look like in practice
The most common failure pattern is a programme that tracks assets but not delegation. It may know which models are approved, which APIs exist, or which cloud accounts are in use, while still having no way to inventory agent instances, agent owners, sub-agents, or the actions each one can perform.
Another failure pattern is broad inherited permissioning. If agents run under shared credentials or platform-wide roles, the programme cannot easily show where one agent ends and another begins. An Zero Trust for AI Agents approach is relevant because it insists on verifying the principal and request, removing standing privilege, and enforcing policy per action.
A third sign is that human review exists only at setup time. If the programme validates an agent once and then never revisits its tool access, delegation path, or runtime behavior, it is treating the agent like static software instead of an active decision-maker. That is where oversight usually breaks down.
Finally, a genuine governance programme can explain what happens when an agent changes state, such as gaining a new tool, spawning a sub-agent, or switching contexts. If those transitions are invisible, the programme is blind to the moments when risk expands fastest.
Risk and Threat Considerations
The main risk is not simply that an agent might misbehave, but that the organisation will not see the behaviour early enough to contain it. When identity, permissions, and traceability are missing, a compromised or over-privileged agent can blend into normal platform noise while still reaching sensitive tools, data, or workflows.
Failure mechanism: Shared credentials, inherited roles, and weak logging create a blind spot where agent actions cannot be tied to a specific principal, so misuse, escalation, or delegated abuse is hard to detect or roll back.
Impact: The result is delayed containment, weak accountability, and an exaggerated blast radius, especially when one agent can invoke tools, call sub-agents, or operate across multiple systems without clear per-action controls.
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 addresses the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 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 fails when identity and authority are not bound to actions. |
| ASI02 — Tool Misuse | The question centers on whether agent tool use is governed and traceable. | |
| Recommendation — Enforce per-action authorization and remove broad inherited agent privileges. Restrict agent tool access to approved actions and log every tool invocation. | ||
| NIST AI RMF | Govern | AI posture programmes are governance systems for accountability, oversight, and control. |
| Recommendation — Define accountability, oversight, and measurable governance controls for agent activity. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Lack of traceability for tool calls and sub-agent activity maps to missing audit events. |
| AC-6 — Least Privilege | Broad inherited permissions are a direct least-privilege failure for agents. | |
| Recommendation — Capture agent actions as auditable events with sufficient detail for reconstruction. Limit each agent to the minimum permissions needed for its approved tasks. | ||
Practitioner Guidance
What to verify: Confirm that the inventory includes individual agents, not just models, apps, or infrastructure, and that each agent has a unique owner, policy boundary, and revocation path. If an agent can act but cannot be named, scoped, and disabled quickly, it is not governed.
Decision rule: If the control evidence is limited to endpoint health, cloud posture, or model configuration, treat the programme as partial visibility and not as agent governance. The evidence should show who acted, what tool was used, which policy permitted it, and whether sub-agent activity is attributable.
Practitioner takeaway: A real AI posture programme governs authority, not just deployment state; if you cannot trace and constrain agent actions at the point of execution, you do not yet have governance.
Related resources from NHI Mgmt Group
- How should organizations approach the governance of AI agents?
- What are the signs that an AI agent safety programme is not actually reducing operational risk?
- What signs show that an identity programme is misclassifying AI agents and NHIs?
- What signs show that an insider programme is not ready for AI agents?