AI security posture management now has to govern agents, not just models

At a glance

What this is: Fiddler argues that AI security posture management now has to govern agents as first-class runtime entities, not just models, because autonomous workflows create identity, permission, and tool-use risk that static scanning misses.

Why it matters: For IAM, NHI, and AI security teams, the shift matters because agent governance depends on per-agent identity, scoped permissions, telemetry, and runtime enforcement rather than cloud-only posture checks.

Context

AI security posture management is the discipline of discovering, assessing, and reducing risk across AI workloads. The article’s core point is that this discipline breaks down when the workload is no longer a static model endpoint but an agent that can choose tools, chain actions, and inherit permissions at runtime.

The governance gap is clear: cloud posture tools can see infrastructure and data stores, but not the agent identity, tool-call permissions, or sub-agent delegation that determine real-world risk. That makes the article relevant to both AI governance and identity control, because autonomous systems now create access decisions that traditional scanning does not govern.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why does runtime behaviour matter more than configuration scanning for agentic AI?

A: Runtime behaviour matters because agents make decisions dynamically, so the risk is created in execution, not only in setup. A static scan can confirm policy at a point in time, but it cannot see an agent that changes tool usage, expands access through delegation, or reaches sensitive data between scans. Governance has to move to the moment of action.

Q: What are the signs that an AI posture programme is not actually governing agents?

A: 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.

Q: What is the difference between AI security posture management and AI governance?

A: AI security posture management focuses on identifying misconfigurations, exposure, and data protection gaps in AI systems. AI governance is broader: it defines inventories, approved use cases, workflows, accountability, and policy controls for how AI is built and used. Strong programs need both. Posture management finds and reduces technical risk, while governance shapes acceptable use and decision making.

Technical breakdown

Why static AI-SPM breaks down with agentic workflows

Traditional AI-SPM assumes a workload that behaves the same way each time it is invoked. Agents break that assumption because they select tools at runtime, chain decisions across steps, and may spawn sub-agents that inherit access from the parent workflow. That makes posture a moving target rather than a fixed configuration. In practice, the control boundary shifts from the model endpoint to the execution tree, where identity, permissions, and side effects all matter at once.

Practical implication: Treat agent execution as the governed object, not just the underlying model or cloud resource.

AI-BOM, identity posture, and permission posture

A mature AI posture programme needs an AI bill of materials, a distinct identity for each agent, and explicit mapping of effective permissions. The AI-BOM tells you what exists and who owns it. Identity posture tells you which agent performed which action. Permission posture tells you what each agent can access, including tools, APIs, data sources, and any inherited sub-agent authority. Without those three layers, there is no reliable inventory, no accountable execution trail, and no defensible scope control for autonomous AI.

Practical implication: Inventory agents separately from models and bind each one to a scoped, auditable identity.

Runtime observability and enforceable guardrails

Runtime observability is what turns AI-SPM from periodic review into active governance. Pre-LLM guardrails can block sensitive prompts before they reach the model, while post-execution guardrails can inspect outputs before they are used downstream. Behavioural baselines add another control layer by flagging drift in tool-call patterns, latency, or external service use. For agentic systems, this is especially important because risk often emerges between scans, not during them. Static posture checks cannot catch an agent that changes its behaviour mid-session.

Practical implication: Enforce policy at execution time and monitor for behavioural drift continuously.

Threat narrative

Attacker objective: The practical objective is to use unmanaged agent access to reach data, code, or infrastructure pathways that security teams cannot inventory or explain.

1. Entry occurs when teams spin up agents with personal API keys or broad filesystem and terminal access, creating unmanaged execution paths that bypass central governance.
2. Credential and permission abuse follows when agents inherit access from parent workflows or use tool permissions that are broader than the task requires.
3. Impact emerges when agents read, modify, or exfiltrate sensitive data and code, or when sub-agents amplify those permissions across additional services and repositories.

Breaches seen in the wild

• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-SPM is becoming an identity-control problem, not just a model-control problem. Once agents can select tools, inherit permissions, and spawn sub-agents, the security question changes from "is the model configured safely" to "is each execution path governed safely". That is a different control plane, and cloud posture tools alone do not reach it. Practitioners should treat agent identity and permission scope as part of the posture baseline.

Agentic hierarchy is the right named concept for this shift. The article describes a decision tree where one agent can create or trigger another, and those subordinate actions can inherit elevated access. That makes runtime governance a hierarchy problem, not a point-in-time scan problem. Organisations that do not model this hierarchy will miss how privilege compounds across agent chains.

Visibility must move to issuance and execution time. The article is explicit that static scans cannot see what an agent does between checks, which means posture review after deployment is too late for meaningful control. The practical consequence is that inventory, telemetry, and enforcement need to sit in the execution path. Security teams should assume that any agent without runtime traces is already outside governable scope.

AI-SPM now sits inside broader AI governance, but security cannot wait for governance maturity to catch up. The article correctly frames compliance, accountability, and documentation as part of the same control story, yet the immediate failure mode is operational invisibility. In governance terms, this is a control-observability gap, and it should be managed as such. Practitioners need policy, evidence, and enforcement aligned before autonomy expands further.

Coding agents create the clearest identity bridge between AI and NHI governance. When an agent can read repositories, write files, and execute shell commands, it is operating through machine credentials and scoped access paths just like other non-human identities. The difference is behavioural volatility, not the access mechanism. That means NHI governance patterns apply, but they have to be extended for runtime decision-making and tool chaining.

From our research library:

• A Harris Poll survey of more than 300 technology decision-makers found that 86% expect agentic AI to deliver positive ROI, yet fewer than half had AI governance policies in place.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agentic AI posture is now an identity governance issue. The article’s main signal for practitioners is that agent behaviour, not just model configuration, has become the risk surface. That pushes AI security toward the same discipline identity teams already apply to privileged workloads: distinct identities, bounded permissions, and continuous evidence. The posture programme that cannot explain an agent’s runtime actions will not hold up in review.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap matters because preparation is now about runtime governance, not just control inventories. Teams that delay agent identity and observability work will keep discovering their blind spots only after autonomy is already in production.

Runtime observability is becoming the control that separates AI governance from AI theatre. If a system can only tell you that a model exists, but not which agent used which tool, on whose behalf, and with what delegated access, the posture programme is incomplete. Practitioners should assume that agentic systems need continuous evidence, not just periodic approval.

For practitioners

• Build a living AI inventory Track every model, agent, pipeline, dataset, and owner in a continuously updated AI-BOM so posture reviews start from complete scope rather than discovered fragments.
• Assign distinct identities to agents Give each agent, including dynamically spawned sub-agents, a unique and auditable identity so tool use, data access, and delegation can be tied to a specific runtime actor.
• Scope tool access by task Limit allowed tools, commands, and APIs to the minimum required for the agent’s function, and explicitly deny code execution or shell access where those actions are not essential.
• Shift guardrails into runtime Use pre-LLM filtering and post-execution checks together so sensitive prompts, unsafe outputs, and drift in behaviour are controlled during execution rather than after the fact.
• Trace agent behaviour end to end Retain spans, tool calls, and sub-agent outputs long enough to reconstruct who did what, when, and through which delegated path if an incident occurs.

Key takeaways

• Agentic AI changes posture management from scanning models to governing runtime actors with identity, permissions, and delegation paths.
• The main blind spot is not cloud infrastructure itself but the agentic execution layer, where tool use and sub-agent inheritance create untracked risk.
• Teams need continuous observability and enforceable guardrails if they want AI autonomy to remain governable in production.

Key terms

• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• Agentic Hierarchy: An agentic hierarchy is the layered structure of AI execution, from individual spans to traces, sessions, and application views. It matters because cost, risk, and policy decisions often happen at the span level, while governance decisions are made higher up the stack.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and IAM patterns that help teams manage autonomous access. It is designed for practitioners who need to connect identity controls to broader security programmes.