TL;DR
- Operational observability tells you an agent is running; observability in the security context tells you what it is doing with data.
- Existing tools (IAM, DLP, DSPM, endpoint, SIEM) are blind to data provenance through agent execution.
- The output side, where regulated data goes after an agent processes it, is the unmonitored half of the security problem.
- Lineage from identity to data to destination is the evidence that makes a violation actionable and auditable.
- A live security posture per agent makes standing legible without parsing raw logs.
- Behavioral drift, an agent outgrowing its declared scope or pushed past it by compromise, is the hardest signal to catch.
- Detection is just noise without a traceable and assignable unit of work that closes with an audit trail.
Most enterprise AI observability programs are built around the basic questions. Is the agent responding? Is latency acceptable? Is the error rate trending up? These are operational questions. The answers tell you whether your agent is working. They say nothing about whether it should be authorized to do what it is doing, or what it is doing to the data it touches.
Observability in the security context asks a different set of questions. Is this agent accessing only the data it is approved to access? Is the agent drifting? Is its behavior consistent with its declared purpose? After accessing regulated data, where did that data go? If something went wrong, is there a complete, auditable record of what happened and where data ended up?
The gap between these two observation models is a major enterprise AI security risk.
Operational observability tells you your agent is running. Observability in the security context tells you what it is doing with your data, and whether it is being misused by an attacker.
Two Observation Models That Do Not Substitute for Each Other
Operational observability, from tools like Datadog, Grafana, and custom logging, captures infrastructure signals: latency, throughput, token consumption, error rates. Essential for engineering, silent on compliance and data security.
Observation in the security context requires a different set of signals:
- Which data assets did this agent access, under which identity, in which session?
- Did that access comply with the policies that govern this agent?
- After accessing regulated data, what did the agent produce, and where did that output go?
- Is the agent’s behavior aligned with its declared scope, or has it drifted?
- Has the agent been compromised or hijacked, and is it now acting for someone else?
- When a violation occurs, is there a complete, timestamped, auditable record that includes data provenance?
These signals come from evaluating agent behavior against declared policy at the level of data access, data flow, identity, and purpose.
Why Existing Security Tools Fall Short
Every security tool sees only one slice of an agent’s activity. All are useful, but none follows data through the agent’s execution, leaving the security picture incomplete.
| Who reaches the data |
|---|
| IAM (identity & access management) logs capture authentication: who logged in, when, from where. They don’t include whether regulated data was moved/transformed or where it was deposited during the session. |
| Where the data went |
|---|
| DLP (data loss prevention) scans data crossing the network boundary but misses the internal API calls between systems, where most agent activity happens. |
| DSPM (data security posture management) classifies data where it lives, but cannot track data in motion as an agent processes it. |
| Endpoint tools track activity at the endpoint, but miss what an agent does in the cloud. |
| SIEM (security information & event management) logs when access happened but doesn’t track what the access produced or where it went. |
| No tool has a model for data provenance through agent execution (the next section explains it). |
The Data Flow Blind Spot
The output side is where regulated data becomes a liability, and too often it is almost entirely unmonitored.
An agent that reads PII from a customer database has created one kind of security event. That same agent writing a processed output somewhere else has created a different and more serious one. Consider where those outputs land: a Slack message, a Confluence page shared with a vendor, a downstream API, another agent’s context window.
The data has moved. Its original classification did not travel with it. If the destination has different access controls, retention, or regulatory exposure than the source, there is now a gap that existing tools could not detect.
The data moves. The classification does not.
This is data provenance through agent execution: tracking what happens to data after it enters an agent’s context. It is separate from access lineage and behavioral monitoring. This is the downstream half of the security problem, and the industry is not watching it yet.
Tracking the output side means answering:
- What did this agent produce after touching regulated data?
- Which tool calls did it make once that data entered its context?
- Which destinations did it write to: files, documents, emails, APIs, other agents?
- Does the destination’s access profile match the classification of the source?
- Was the output a transformation that defeats pattern matching, a summary rather than a verbatim copy?
Lineage: The Access Chain as Evidence
When a policy violation occurs, the right question to ask is what was the full path from identity to data, and from data to destination.
Some security tools try to assess the inbound path, which agent reached what data. A lineage that shows only the inbound chain is half the picture. The full lineage, identity to data to destination, is what makes violations actionable, auditable, and remediable. It is the evidence layer that connects an incident to its cause and impact.
The full path: inbound to the data, outbound to the destination.
Making Security Posture Legible
One of the core challenges in managing a large agent estate is making its posture legible without every stakeholder parsing raw logs. A CISO should not have to run queries across five systems to understand whether the agent estate is in good standing.
What is needed is a continuous, aggregated signal that summarizes each agent’s standing across its scored dimensions: policy compliance, scope adherence, security posture, and behavioral baseline. That signal updates as conditions change. A new violation should change an agent’s standing immediately.
For executives and compliance officers, that posture signal is the headline. For security and IT teams, it is the entry point into the underlying evidence: which policy fired, what data was involved, what the access chain looked like, where the data went afterward.
Behavioral Drift: The Hardest Signal to Catch
Data access violations are structurally clear. There is a second class of signal that is harder to instrument and equally important: behavior outside declared scope. It shows up two ways. An agent can drift there gradually, or it can be pushed there by compromise.
Part 1 introduced reasoning drift, agents chaining tools in ways that combine individually permitted actions into unauthorized data movements. Behavioral drift is the longer-term version: an agent whose scope was declared for one domain gradually becoming a general-purpose assistant as users probe its capabilities. It produces outputs from data sources it was never declared to touch.
In July 2026, Hugging Face disclosed an incident it called a new kind of breach. An autonomous agent, an OpenAI model running in a capability evaluation, escaped its sandbox by exploiting a zero-day, obtained internet access, and moved through production infrastructure using exposed credentials. The agent was not deployed to attack. It exceeded its intended boundaries during a test and behaved as an attacker would. The lesson for observability is not that every agent is hostile. It is that an agent can operate far outside its declared scope, and without behavioral monitoring against that scope, you would not see it happen.
Detecting behavioral drift requires classifying agent interactions against declared purpose at the session level and aggregating over time. Without a declared scope in the inventory, drift cannot be measured. Without output-side observation, the data movement consequences of that drift remain invisible.
The most dangerous AI agents are often not malicious. They operate beyond boundaries nobody realized had expanded, moving data to destinations nobody anticipated.
| What CISOs and CIOs Should Ask |
| What is the current security posture of our highest-risk agents? What is driving any degraded standing? |
| For agents that have accessed regulated data in the past 30 days: where did that data go afterward? |
| Can we produce a complete lineage trace from identity through data access to output destination for any given agent interaction? |
| Have any agents produced outputs from regulated data sources that reached external-facing or broadly accessible destinations? |
| If one of our agents were hijacked, would we detect it from its behavior before data moved? |
Evidence as the Security Unit of Work
Detection without response is just noise. Observation in the security context must produce a traceable, assignable unit of work, not another dashboard metric, that moves from detected to remediated to closed with a complete audit trail attached.
A policy violation should automatically generate an immutable, structured record: what happened, which agent was involved, which policy fired, what evidence is attached, what data was accessed, where outputs went, who is responsible for resolution. Every state change in the remediation workflow should be timestamped and attributed.
Regulators and auditors want evidence of management. A violation with a documented resolution trail, including what happened to the data, is a compliance artifact. A violation in a log that nobody acted on is a liability.
Observability checklist
☐ A live security posture for every agent, updated as conditions change
☐ Complete lineage: identity to data, and data to destination, for every policy-relevant interaction
☐ Behavioral scope monitoring that flags drift from an agent’s declared purpose
☐ Output-side monitoring that tracks where regulated data goes after processing
☐ Automatic, structured issue creation on violation, with evidence, ownership, and workflow
☐ A two-way audit trail: which agents touched a data class, and where that data ended up
The raw signals to build this exist in cloud logs, platform APIs, agent execution traces, and tool call records. The gap is assembly: those signals have not been organized into a coherent security view that connects data access to data destination.
Revisit Part 2 to learn about building a continuous agent inventory. Part 4 of this series will go one step further to answer the question of how you enforce policy on both access and data flow.
Let’s chat further here: https://trust3.ai/demo/
