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

At a glance

What this is: This is Fiddler’s analysis of why AI security posture management must move from model-level scanning to agent-level governance, with identity, permissions, tools, and runtime behaviour treated as first-class control points.

Why it matters: It matters to IAM practitioners because agentic AI introduces non-human identities that need auditable identity, scoped access, and lifecycle governance across both AI and broader identity programmes.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Fiddler's analysis of AI security posture management for agents

Context

AI security posture management is no longer just a control problem for static models. As organisations deploy agents that can select tools, chain decisions, and act across systems, the governance gap shifts from infrastructure visibility to agent identity, permission scope, and runtime accountability.

In a mixed AI estate, the same cloud controls that can flag a misconfigured bucket or IAM rule cannot tell whether an agent is making legitimate decisions, inheriting excess privilege, or operating without formal ownership. That makes AI-SPM relevant to IAM and NHI programmes because agents behave like governed identities, not just workloads.

Key questions

Q: What should organisations rethink when AI agents can act without human approval?

A: Organisations should rethink review cycles, revocation timing, and accountability assumptions. If an agent can complete a task before a human review occurs, then access reviews no longer capture the full risk. Governance has to move to runtime policy, per-agent identity, and machine-speed lifecycle controls.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What do organisations get wrong about AI posture management?

A: The most common mistake is treating AI posture management as a better version of CSPM. That misses the point entirely, because AI workloads need identity, permission, and behavioural controls that operate at the semantic layer. Another mistake is assuming a daily scan can catch a dynamic agent that drifts between executions.

Q: When should organisations tighten controls on coding agents?

A: Organisations should tighten controls as soon as a coding agent can read repositories, access terminals, or reach infrastructure-as-code templates. Those capabilities create direct pathways to secrets, deployment changes, and code tampering. The safest default is least privilege, pre-merge review, and explicit limits on shell and repository access.

Technical breakdown

Why static posture scanning fails for agentic AI

Traditional posture management assumes workloads behave predictably: the same inputs produce the same execution path, and configuration state changes slowly enough for periodic scanning to work. Agentic AI breaks that assumption because it can choose tools at runtime, branch across multiple steps, and spawn sub-agents that inherit permissions. That means the security problem is not only misconfiguration, but also how capability changes during execution. Static tools may see an allowed service account or a compliant IAM policy, yet still miss unsafe tool use, delegated access, or cross-system actions that emerge only in runtime.

Practical implication: treat runtime evaluation as mandatory for agentic workloads, not an optional enhancement to daily posture scans.

Agent identity and permission posture define the real control boundary

Agent posture management depends on being able to answer two questions precisely: which agent acted, and what that agent was allowed to do at that moment. That requires unique agent identities, auditable delegation, scoped tool permissions, and limits on sub-agent inheritance. Without that boundary, multiple agents collapse into an undifferentiated application tier, which destroys accountability and weakens least privilege. In identity terms, the agent is the principal, the tools are the resources, and the policy must follow the runtime decision path rather than a static application label.

Practical implication: assign per-agent identities and enforce per-agent policy decisions across tool calls, data access, and delegation chains.

Runtime observability is what turns AI posture into governance

AI-SPM becomes meaningful when it captures evidence of what happened during execution, not just what was approved beforehand. Span-level telemetry, behavioural baselines, and pre- and post-execution guardrails provide that evidence layer. Pre-LLM controls limit prompt exposure before the model acts, while post-execution controls inspect outputs before downstream systems consume them. This is especially important for coding agents and other autonomous systems that can read files, run commands, and change production-adjacent content. In governance terms, observability is the bridge between policy and enforcement.

Practical implication: build trace retention, behavioural baselines, and independent input and output guardrails into AI governance workflows.

Threat narrative

Attacker objective: The objective is to exploit opaque agent behaviour and inherited privilege to reach data, code, or systems without reliable detection or accountability.

1. Entry occurs when shadow AI is created with personal API keys or broad tool access, often outside formal inventory and ownership. Escalation follows when an agent inherits permissions, chains tool calls, or spawns sub-agents that expand effective access beyond the original use case. Impact appears when the agent reaches sensitive data, modifies code, or triggers downstream actions that the security team cannot fully reconstruct because telemetry and identity evidence were incomplete.

NHI Mgmt Group analysis

AI posture management is becoming identity governance for machines that act. Once an agent can choose tools, inherit access, and produce side effects, it stops behaving like a passive model endpoint and starts behaving like a governed principal. That shifts the control question from model safety to identity assurance, permission scoping, and evidence capture. Practitioners should read AI-SPM as an extension of NHI governance, not as a renamed cloud scan.

Agentic AI creates a posture gap that CSPM and DSPM cannot close. CSPM can see infrastructure state and DSPM can classify data, but neither can tell whether an agent should access a dataset, invoke a tool, or spawn a sub-agent. That is a semantic control problem, not a resource inventory problem. Agent posture gap: the blind spot between infrastructure visibility and runtime authorisation for AI systems. The practitioner conclusion is that AI governance needs its own control plane.

Shadow AI is not just an inventory problem, it is an identity problem. When teams spin up agents with personal API keys or unowned sandboxes, the issue is not merely that the asset is undocumented. The deeper failure is that the organisation has no durable way to bind action, ownership, and privilege to a specific machine actor. That weakens accountability across IAM, compliance, and incident response. Practitioners should treat unowned agents as unmanaged identities until proven otherwise.

Coding agents expose the fastest path from AI assistance to privilege abuse. File access, terminal access, and repository access create direct pathways to secrets exposure, dependency injection, and code tampering. The governance lesson is that development agents need stricter controls than general-purpose assistants because they operate where identity, code, and deployment boundaries converge. Practitioners should prioritise code-facing agents for the strongest runtime controls and review gates.

What this signals

Agentic AI governance is converging with NHI lifecycle management. As AI systems begin to act independently, the operational question becomes who owns the identity, what it can access, and how quickly that access can be revoked when behaviour changes. That is the same lifecycle logic used for other non-human identities, but now it must extend into runtime decisions and tool chains. The programme implication is simple: if an agent can act, it needs the same governance discipline as any other privileged machine identity.

The control gap will widen fastest where teams have high volumes of shadow AI and low telemetry coverage. Organisations that cannot track what their agents access will struggle with both compliance and incident reconstruction, especially when one agent’s output becomes another system’s input. That makes evidence retention and delegated-access review part of the security baseline, not a specialised add-on.

Runtime observability is the named concept practitioners should internalise. It means posture is not a point-in-time scan but a continuous view of identity, tool use, and behaviour across the full execution path. For readers building AI controls, that shifts investment toward traceability, policy enforcement, and audit-ready evidence rather than one-off hardening exercises.

For practitioners

• Define unique identities for every agent Bind each AI agent to a distinct identity, ownership record, and policy scope so that tool calls and delegated actions remain auditable across runtime sessions.
• Inventory AI workloads as governed assets Maintain a living AI-BOM that records every model, agent, pipeline, dataset, and external service so that shadow AI cannot hide outside approved governance.
• Separate pre-input and post-output controls Use pre-LLM filters to block prompt injection, secrets, and sensitive data before model execution, then apply post-execution review before outputs reach users or downstream systems.
• Set runtime limits on tool use and delegation Cap tool calls, restrict allowed tools, and deny sub-agent creation unless there is a documented use case and explicit approval path for the session.
• Prioritise coding agents for stronger review Require pre-merge review, repository scoping, and shell-command restrictions for coding agents that can reach source code, infrastructure templates, or embedded credentials.

Key takeaways

• AI security posture management now has to govern agent identity, permissions, and runtime behaviour, not just model configuration.
• The strongest evidence in the article is the mismatch between static controls and dynamic AI behaviour, which leaves major blind spots for ownership and auditability.
• Practitioners should move AI agents into explicit identity and access governance with runtime monitoring, scoped tools, and enforceable evidence capture.

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.
• Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Fiddler's full blog covers the operational detail this post intentionally leaves for the source:

• A practical breakdown of AI-SPM capability requirements, including AI-BOM inventory, supply chain assessment, and runtime policy enforcement.
• Examples of posture policies for agent identity, tool permissions, execution limits, and telemetry retention across agentic workflows.
• A deeper treatment of coding-agent posture management, including repository scope, shell access, and pre-merge review boundaries.
• The article's discussion of agentic hierarchy and span-level telemetry across multi-agent decision trees.

👉 Fiddler's full post covers agent identity, tool-chain posture, and runtime guardrails in more implementation detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners building policy, ownership, and auditability into modern identity programmes.