Introducing DACSA: A Data-Centric Authorization Model for Agentic AI
In my last post, I argued that the security community is applying action-based controls to agentic AI systems whose risk is fundamentally data-based — and that this gap requires something additional to what we have today. Not a replacement for existing authorization frameworks, but a new layer designed to govern what current models cannot: what happens to the data after access is granted.
I received a lot of responses to that post — and the most common question was straightforward: “Okay, so what does that actually look like?”
This is my answer. I want to introduce DACSA — Data-Centric Authorization for Securing Agentic systems — a model I’ve been developing that shifts enforcement from the action layer to the data layer.
The Core Shift
Traditional authorization asks one question at the point of access: “Is this action permitted?”
DACSA asks four questions — continuously — throughout the entire data lifecycle:
- What is the sensitivity of this data? (Classification)
- Where has this data been, and how has it changed? (Lineage)
- Does this transformation increase exposure? (Delta Inspection)
- Does this output violate constraints? (Output Enforcement)
These four questions form the pillars of the model. Each one addresses a specific failure mode that action-based controls cannot reach. Together, they provide a framework for governing data in systems whose behavior is non-deterministic — which is precisely what agentic AI systems are.
Pillar 1: Sensitivity Classification
Every piece of data entering an agent’s environment gets tagged with a sensitivity label. The labels follow a lattice structure inspired by the Bell-LaPadula model — the foundational mandatory access control model from 1973 that formalized the principle of “no read up, no write down.” In DACSA, data can flow from lower classification levels to higher ones, or laterally within the same level — but it cannot flow downward without explicit declassification.
| Level | Label | Example |
|---|---|---|
| L0 | Public | Published content, public APIs |
| L1 | Internal | Internal documentation, team communications |
| L2 | Confidential | Customer data, financial records |
| L3 | Restricted | PII, health records, legal discovery |
| L4 | Regulated | Data subject to specific legal frameworks (GDPR, HIPAA) |
The critical property is propagation. Labels are applied at ingestion and they follow the data through every transformation. A summary of L3 data is still L3. An embedding generated from L2 documents carries an L2 classification. A response that combines L1 and L3 inputs inherits L3 — the “high water mark” principle.
Pillar 2: Lineage Tracking
DACSA maintains a directed acyclic graph of data provenance. Every piece of data in the system has a lineage record that captures where it originated, every operation that modified or combined it, which agents touched it, when each transformation occurred, and the task or goal under which the data was accessed.
If this sounds familiar to anyone who has worked in software supply chain security — it should. It is the same principle. We trace a compiled binary back through every build step, every dependency, every transformation from source to artifact — because we learned that the individual steps can all be legitimate and the outcome can still be compromised.
Lineage tracking gives you two things:
Forensic visibility — after an incident, you can reconstruct exactly how sensitive data reached an unauthorized destination. Not a guess. A complete graph from origin through every transformation to the point of exposure.
Runtime policy evaluation — lineage enables policies that reason about data history, not just data state. For example: “data that originated from the HR system and has been combined with data from the finance system requires L3 classification, regardless of the classification of either source independently.” This is composition-aware policy — the thing that action-based models fundamentally cannot do.
Pillar 3: Delta Inspection
This is the pillar I think is most missing from the current landscape — and the one that addresses the threats no existing control mechanism catches.
Delta inspection evaluates the relationship between an agent’s inputs and its outputs. It operates on three dimensions:
Sensitivity delta — does the output contain information at a higher sensitivity level than the output channel permits? This catches direct leakage.
Information delta — does the output contain information that was not present in any single input but emerges from their combination? This catches aggregation attacks. An agent that queries an employee directory for names, a compensation system for salary bands, and an org chart for team assignments has — in each individual query — accessed non-sensitive data. But if the output reconstructs individual salary information, new sensitive information has been created.
Inference delta — does the output enable a recipient to infer sensitive information that is not explicitly stated? An agent with access to a medical database, asked to “suggest a birthday gift for the user,” might recommend items related to a medical condition — disclosing health information through inference without ever outputting a diagnosis.
Pillar 4: Output-Bound Enforcement
This is the architectural insight I keep coming back to: for systems whose internal behavior is non-deterministic, the most reliable enforcement point is the output boundary — not the input boundary.
Output-bound enforcement has three mechanisms:
Sensitivity caps — every output channel carries a maximum classification level. An agent operating on L3 data cannot produce output on an L1 channel without explicit declassification. This is a hard constraint — enforced deterministically, not probabilistically.
Contextual integrity checks — data has a context it belongs to. HR data belongs in HR operations. When an agent attempts to emit data outside its originating context — even through a chain of authorized actions — the contextual integrity check flags it.
Rate and pattern constraints — these address the low-and-slow aggregation threat. A single query returning a salary band is normal. Fifty queries — each returning a different salary band for a different level — is an exfiltration pattern.
Applying DACSA to Real Incidents
EchoLeak (CVE-2025-32711)
A crafted email triggered Microsoft 365 Copilot to exfiltrate internal data through a chain of individually permitted operations.
Under DACSA: the data tagging layer classifies internal content at L2 or higher. The lineage tracker follows that data from email processing through to the image fetch request. Delta inspection flags the output — internal data is being encoded in URL parameters destined for an external endpoint. The output enforcer checks the image-fetch channel’s sensitivity cap — L0 for external requests — and blocks L2+ data. The exfiltration is stopped at the output boundary.
Log-To-Leak (MCP Exploit)
Prompt injection forced an MCP-connected agent to write the full conversation history to a malicious logging tool.
Under DACSA: conversation data inherits the classification of its content. The contextual integrity check identifies a violation — conversation data has an intended context (the user session), and flowing it to an external logging service violates that context. The output enforcer applies the logging channel’s sensitivity cap and blocks the write.
Low-and-Slow Aggregation
An agent queries an employee directory, a compensation system, and an org chart — each returning non-sensitive data in isolation. The output combines all three to reconstruct individual salary data.
Under DACSA: the lineage tracker records the combination. Lineage policy escalates classification when these datasets are combined. Delta inspection evaluates the information delta — new information has been created that did not exist in any single input. The aggregation is caught.
What DACSA Does Not Do
DACSA does not catch semantic misuse within an authorized context. An agent that uses legitimate data access to build unauthorized behavioral profiles — without the data ever leaving its authorized context — is beyond what a data-flow model can detect.
DACSA depends on accurate classification. Misclassified data degrades the system. Automated classification is imperfect. Manual classification does not scale.
Runtime inspection introduces performance overhead. Lineage tracking and delta inspection add latency. The tradeoff between security depth and performance is real.
Evasion is possible. Sophisticated attackers might encode sensitive data in ways that evade content inspection. The arms race between encoding and detection is inherent to any content-inspection approach.
These are real limitations. They are not reasons to avoid building the model. They are reasons to build it with clear eyes.
Where This Goes Next
DACSA is a model — not a product. The formal paper, including the complete model specification, differentiation from related work like Microsoft’s FIDES, and detailed case study analysis, will be published soon.
If you’re building in this space, I’d welcome the conversation. If you’re securing agents today and struggling with the gap between what your authorization model covers and what your agents actually do with data — that gap is exactly what DACSA is designed to address.
The action layer is necessary; however, it is not sufficient. The data layer is where we can close that gap.
This is the second post in a series on data-centric authorization for agentic AI systems.
AI Citation: AI assisted with this blog post with formatting and additional context using Claude Opus 4.6 with (1M) context.