At RSA Conference in late April 2026, Palo Alto Networks announced an expansion of its AI Security Posture Management capabilities within Prisma Cloud that received less attention than it deserved. The announcement described what the company calls "agent activity profiling" — a runtime layer that builds behavioral baselines for agentic AI systems by observing their actual tool calls, data access sequences, and external API interactions over time. The stated goal is to detect when an agent's behavior deviates from its established pattern, even when that behavior remains technically within the permissions it was granted.
That last clause is the important one. An agent operating within its configured permissions but deviating from its behavioral baseline is, depending on which governance architecture you're consulting, either fine or suspicious. Palo Alto is building infrastructure that says suspicious. The provisioning system says fine. Both are correct by their own logic. That is the problem this piece is about.
What AI-SPM Was
AI Security Posture Management, as it existed through most of 2024 and into 2025, was essentially configuration scanning applied to AI systems. The questions it asked were prospective and structural: What models are deployed? What data can they access? What permissions have been granted? Are those permissions overly broad? Does this AI pipeline expose sensitive data to an external API it shouldn't be calling?
These are legitimate questions. They're also the same questions that cloud security posture management asked about infrastructure, and identity governance asked about users. The mental model was familiar: enumerate the assets, map the permissions, flag the misconfigurations. Palo Alto was not alone in this framing — it was the industry's default approach to AI security, because it fit the tools and organizational processes that security teams already had.
The limitation of that framing is that it treats an AI agent the way it treats a storage bucket: as a thing with a configuration that can be audited. Agents are not storage buckets. They make decisions. They sequence actions. They call tools in combinations and orders that their designers may not have fully anticipated. A misconfigured storage bucket sits there being misconfigured. A misconfigured agent does things.
The Behavioral Turn
Palo Alto's expansion into agent activity profiling is an architectural shift, not a feature increment. The company has described the capability as moving from "configuration posture" to "behavioral posture" — a phrase that sounds like marketing but actually names a real distinction. Configuration posture asks what an agent is allowed to do. Behavioral posture asks what an agent is actually doing, and whether that pattern looks normal.
To build a behavioral baseline, Palo Alto's system needs runtime telemetry: logs of which tools the agent called, in what sequence, with what parameters, accessing what data, at what frequency. This telemetry has to be collected continuously, stored, and analyzed against a model of what "normal" looks like for this agent in this context. The company has been integrating with AI orchestration frameworks — LangChain, LlamaIndex, and similar platforms — to instrument agent execution at the framework level, capturing the granular action sequences that higher-level logs would obscure.
Job postings from early 2026 show Palo Alto hiring specifically for "AI runtime security" engineering roles, with requirements around distributed tracing, behavioral anomaly detection, and agentic workflow instrumentation. The hiring pattern is consistent with building the telemetry infrastructure that behavioral baselining requires. This is not a trivial engineering problem. Agents running complex multi-step tasks can generate thousands of discrete actions in a single session; distinguishing a legitimate but unusual sequence from a genuinely anomalous one requires models trained on substantial baseline data.
The technical challenge is real, but the more consequential thing Palo Alto is building here is a different kind of record.
The Record Problem
Every governance architecture produces a canonical record of what happened. That record determines who is accountable, to whom, and for what.
A configuration record says: it was allowed to do what it did. A behavioral record says: what it did looked like what it normally does. Both can be true simultaneously. Both can be false simultaneously.
Provisioning-side governance produces a configuration record. It says: this agent was granted these permissions, by this team, on this date, under this policy. When something goes wrong, the configuration record is the primary artifact. The question it answers is whether the agent operated within the scope it was given. Accountability flows to whoever made the provisioning decision — the platform engineering team, the IT organization, the team that deployed the agent. The record lives in the IAM system, the orchestration config, the policy engine.
Threat-detection-side governance produces a behavioral record. It says: this agent made these calls, in this sequence, accessing this data, at this time. When something goes wrong, the behavioral record is the primary artifact. The question it answers is whether the agent's actions looked normal relative to its established pattern. Accountability flows to whoever was monitoring — the security operations team, the SOC, the AI risk function. The record lives in the SIEM, the XDR platform, the behavioral baseline database.
These are not two implementations of the same governance idea. They are different epistemological commitments about what counts as evidence that an AI system behaved appropriately. And critically, one can be true while the other is false.
The scenario that Palo Alto's agent activity profiling is specifically designed to catch: an agent that has been compromised through prompt injection or indirect manipulation begins calling tools it is legitimately permitted to call, but in sequences and combinations that deviate from its baseline. The provisioning record shows no violation — every action was within scope. The behavioral record shows a clear anomaly. From the provisioning side, nothing went wrong. From the detection side, something is very wrong.
The inverse is equally plausible: an agent whose baseline was established during a period of unusual activity, or whose task distribution has legitimately shifted as the business changed, begins flagging as anomalous even though it is operating exactly as intended. The behavioral record shows a deviation. The provisioning record shows full compliance. Which record is authoritative?
The Organizational Fracture
The record problem would be manageable if both records lived in the same organizational function. They do not, and they are unlikely to.
Provisioning-side governance is owned by the teams that deploy and manage AI systems: platform engineering, IT, the business units running AI-powered workflows. These teams think in terms of policy, permissions, and lifecycle management. Their accountability horizon is the deployment decision. They are responsible for what the agent was allowed to do.
Threat-detection-side governance is owned by security operations. These teams think in terms of signals, anomalies, and incident response. Their accountability horizon is the monitoring function. They are responsible for what the agent was observed doing.
In most enterprises, these functions report through different chains of command, operate on different toolsets, and have different relationships with the business units they serve. Platform engineering is typically closer to the product and engineering organizations. Security operations is typically closer to the CISO and the risk function. When an AI agent does something unexpected, these two functions will often reach different conclusions about what happened, who is responsible, and what the appropriate response is.
This organizational tension has a familiar shape — it is a version of the longstanding friction between development and security, between "we built it to spec" and "the spec didn't anticipate this." What makes the AI agent case structurally different is the nature of the canonical records. In traditional software security incidents, the code is the artifact. Both the development team and the security team can examine the same codebase. The disagreement is about interpretation, not about what the primary record is.
With AI agents, the primary records are genuinely different artifacts produced by different systems for different purposes. The configuration record and the behavioral record are not two views of the same data. They are different data, owned by different teams, answering different questions. When they disagree, there is no obvious arbiter.
The Reconciliation Gap
Enterprises will not choose between these architectures. They will operate both simultaneously, because the regulatory and business pressures driving each are independent. Provisioning-side governance is required by access management frameworks, data governance policies, and the emerging wave of AI-specific regulation that focuses on what AI systems are permitted to do. Behavioral monitoring is required by security operations mandates, incident response obligations, and the practical reality that permitted behavior and safe behavior are not the same thing.
The governance gap that emerges is fundamentally a reconciliation problem, not a technology one. Palo Alto can build excellent behavioral baselining. The IAM vendors and orchestration platforms can build excellent configuration governance. The gap is: when the two records disagree, what is the process for determining which one is authoritative, who resolves the conflict, and what the resolution means for accountability?
There is no established answer to this question. Audit standards for AI systems are still being written, and the ones that exist tend to focus on either the provisioning side (what was the agent authorized to do?) or the detection side (was anomalous behavior flagged?) without specifying how conflicts between the two should be resolved. The EU AI Act's requirements around high-risk AI systems emphasize human oversight and logging, but do not specify a canonical record format or an organizational owner for that record. The NIST AI Risk Management Framework is similarly agnostic about which governance architecture should be primary.
Reconciling the two architectures will require something that neither Palo Alto nor the IAM vendors can build alone: a shared data model that can express both policy compliance and behavioral anomaly in a common format, and an organizational function with the authority to arbitrate between them. The shared data model is a tractable engineering problem — it requires agreement on schema and telemetry standards, which is the kind of thing that eventually gets solved through industry consortia or regulatory mandate. The organizational function is harder. It requires enterprises to create a role that sits above both platform engineering and security operations, with the authority to say which record governs when they conflict.
Some enterprises are beginning to build this under the label of "AI governance" or "AI risk management," typically housed in the risk or compliance function. The problem is that these functions are often staffed with people who understand policy and compliance but not the technical details of how behavioral baselines are constructed or what a meaningful deviation looks like. The security operations team understands the detection side but may not have the organizational authority to override a provisioning decision made by platform engineering. The platform engineering team understands the configuration side but may not have visibility into the behavioral telemetry that the SOC is watching.
Palo Alto's move into agent behavior baselining is strategically coherent as a product decision. It extends the company's detection capabilities into a new and growing surface area, and it positions Prisma Cloud as the system of record for what AI agents actually do at runtime. That is a valuable position to hold. But the value of holding it depends on enterprises eventually deciding that the behavioral record is the authoritative one, or at minimum that it has equal standing with the configuration record in any governance dispute.
That decision has not been made. A product announcement cannot make it. It will be made, slowly and inconsistently, through regulatory guidance, audit failures, and the accumulation of incidents where the two records disagreed and someone had to decide which one mattered. Palo Alto is building the infrastructure for one side of that argument. The argument itself is still open.