Pillar’s AI security pivot shows behavior now matters more than code

At a glance

What this is: This is a Pillar Security news post arguing that AI security must shift from code scanning to continuous monitoring of agentic behaviour and lifecycle governance.

Why it matters: It matters because identity teams now have to govern AI as an operational actor inside workflows, where drift, misconfiguration, and runtime privilege use can affect NHI, autonomous, and human identity controls alike.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Pillar Security’s commentary on why AI security is shifting from code to behaviour

Context

AI security is no longer just a model-hardening problem. Once an AI system is wired into workflows, decision paths, and operational tooling, security has to account for how that system behaves in production, how it changes over time, and how its access is governed across the full lifecycle.

Pillar Security’s post is really a commentary on that shift. The central issue is agentic behaviour inside business operations, where traditional AppSec scanning and static controls miss the runtime risks that matter to identity, access, and compliance teams.

Key questions

Q: How should security teams govern AI systems that operate inside business workflows?

A: They should govern them as operational actors with runtime access, not as isolated software components. That means defining ownership, monitoring live behaviour, and enforcing policy where actions occur. If an AI system can query data or trigger workflow steps, access review and runtime controls must cover the delegated privileges it actually uses.

Q: What breaks when AI security is limited to AppSec scanning?

A: Static scanning misses emergent behaviour, so the organisation can approve code that later behaves outside policy in production. The failure is a mismatch between what was reviewed and what actually runs. Teams end up with technical assurance on the build, but no visibility into runtime drift, tool misuse, or overreach.

Q: How do you know if an AI governance programme is actually working?

A: It is working if you can show the system’s real access, real actions, and real deviations from approved behaviour. Useful signals include baseline coverage, alert quality on drift, and whether policy enforcement can stop an unsafe action before it completes. If those signals are missing, the programme is mostly documentation.

Q: Why do AI systems complicate identity and access governance?

A: Because they can act inside business processes while carrying delegated access that is neither purely human nor purely machine-like. That creates shared responsibility across IAM, NHI, and operational security teams. Governance has to track behaviour, privilege, and ownership together, or the system’s effective authority will outrun its controls.

Technical breakdown

Why static AppSec misses agentic behaviour

Traditional application security tools are built to inspect code, dependencies, and known vulnerabilities. They are poor at detecting emergent behaviour, which is what happens when an AI system begins making context-sensitive decisions inside live workflows. In practice, the risk is not only whether the model code is secure, but whether the system starts acting outside its intended operating envelope after deployment. That includes unsafe tool use, unpredictable sequencing, and policy drift that only appears at runtime. Static review can validate inputs and software components, but it cannot reliably predict how an AI-enabled workflow will behave once it is coupled to business logic and external systems.

Practical implication: treat AI runtime behaviour as a separate control plane from code review and application scanning.

Agentic drift and continuous monitoring

Agentic drift is the gap between intended AI behaviour and observed behaviour in production. A system can remain technically functional while still crossing policy boundaries, overreaching on data access, or taking actions that were never approved at design time. Continuous monitoring matters because it creates a baseline of normal behaviour and then compares live activity against that baseline. This is closer to behavioural governance than traditional vulnerability management. For identity teams, the key point is that the monitored object is not just the model, but the operational identity that can invoke tools, touch data, and trigger downstream actions.

Practical implication: baseline AI behaviour early and alert on deviation before drift becomes business logic.

Runtime guardrails for AI in business workflows

Runtime guardrails are controls that intervene during execution, not after the fact. They can block, constrain, or correct behaviour when a system attempts an action outside policy. That becomes important once AI is embedded into workflows that already carry sensitive privileges, because the control must operate at the moment of decision rather than at deployment time. The architectural shift is from preventive approval to continuous enforcement. In identity terms, this pushes AI governance closer to zero standing privilege, policy enforcement, and delegated access constraints, but with the added requirement that the control can react while the system is actively using that access.

Practical implication: place policy enforcement at runtime, where AI decisions become actions, not only at deployment gates.

NHI Mgmt Group analysis

AI security is becoming an identity governance problem, not only an application security problem. Once AI systems sit inside business workflows, their behaviour determines who can access what, when, and under which policy assumptions. That is a governance problem because the meaningful control surface is runtime access, not merely code quality. Security teams need to treat AI-enabled workflows as governed operational actors, not as isolated software components.

Agentic drift is the named failure mode this market is converging on. The term captures the widening gap between intended and observed AI behaviour once tools, data, and decision rights are combined in production. Static controls assume the system stays within the boundaries designed at build time, but agentic behaviour can alter those boundaries after deployment. The implication is that governance must be based on observed behaviour, not only on design intent.

Continuous monitoring is now the minimum viable control for AI systems with operational reach. If a system can trigger actions, query data, or move through workflows independently, then periodic review is structurally too slow to catch meaningful misuse. The issue is not simply detection, but temporal mismatch between governance cadence and runtime behaviour. Practitioners should read this as a signal that behavioural baselining has become part of identity control.

Runtime guardrails are where AI governance and access governance begin to overlap. The same access that allows an AI system to be useful also creates the path for overreach, accidental disclosure, or policy violation. That means AI governance cannot stay separate from NHI and IAM oversight. The field is moving toward unified controls that follow the actor across discovery, posture, testing, runtime enforcement, and compliance.

Security programmes that only classify AI as a tool will understate its operational risk. Pillar’s framing reflects a broader industry reality: once AI participates in decisions and workflows, it behaves more like a governed operational actor than a passive utility. That does not make every AI system autonomous, but it does make behaviour and access the primary concern. Practitioners should align governance to the way the system actually operates, not to how it is labelled.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a deeper control lens, read OWASP NHI Top 10 for the risks that runtime AI behaviour creates when tools and identity intersect.

What this signals

Agentic drift will become a board-visible governance metric before it becomes a mature security category. With 98% of companies planning to deploy more AI agents in the next 12 months, the control problem is scaling faster than policy design. Identity teams should expect pressure to prove where AI is acting, who owns it, and what happens when behaviour strays from the approved baseline.

Runtime enforcement will matter more than model approval. If AI can touch data and trigger workflows, then the relevant question is no longer whether the model was reviewed, but whether the system can be stopped mid-action when it exceeds scope. That pushes practitioners toward behavioural baselines, runtime policy, and tighter ownership mappings across AI, NHI, and IAM programmes.

For practitioners

• Baseline live AI behaviour before expanding access Capture normal tool calls, data access patterns, and workflow paths for each AI-enabled system, then compare production activity against that baseline so drift is visible early.
• Separate code review from runtime governance Keep AppSec scanning for code and dependencies, but add operational controls that watch how the AI behaves after deployment, especially when it can invoke internal tools or sensitive datasets.
• Map AI-enabled workflows to identity and access owners Assign clear ownership for every AI system that can touch business data or trigger actions, and make the access review include the workflow, the data, and the delegated privileges together.
• Enforce policy at the point of execution Use runtime guardrails to block or correct actions that exceed approved scope, rather than relying only on pre-deployment checks that cannot see behavioural drift.

Key takeaways

• The core risk is not just AI capability, but AI behaviour once it is embedded in business workflows.
• Most organisations are still behind the curve on agent governance, even as deployment plans accelerate and rogue behaviour is already common.
• Practitioners need runtime visibility, ownership, and enforcement if they want AI governance to keep pace with operational use.

Key terms

• Agentic Drift: The gap between intended AI behaviour and the actions an AI system actually takes in production. It matters because a system can remain technically healthy while still crossing policy boundaries, misusing tools, or accessing data in ways the organisation never approved.
• Runtime Guardrails: Controls that evaluate and constrain behaviour while an AI system is running. They are different from build-time checks because they can block or correct an unsafe action at the moment it is attempted, which is essential when AI participates in live workflows.
• Behavioural Baseline: A record of normal access patterns, tool use, and workflow actions for a system. In AI governance, it provides the comparison point for spotting drift, overreach, and unusual actions that traditional code scanning would not reveal.
• Operational Actor: A system that can influence business processes through data access, tool invocation, or action execution. For identity teams, the term helps distinguish AI systems that merely generate output from those that participate in governed workflows and therefore need access oversight.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Pillar Security: Why I’m Joining Pillar. Read the original.