Authorised to read is not authorised to remember
ARISE literature spends most of its pages on identity, intent, and whether the action should proceed. That is the right centre of gravity. It leaves a hole that incident responders already know: the call was allowed, and the payload was a problem.
A support agent with a legitimate GET on a customer record does not need stored card numbers, tax identifiers, session cookies, or the internal notes field a human added in 2019. Those fields still arrive in the JSON because the API was built for a trusted application, not for a model that will keep the object in context, write it to a trace, forward it to the next tool, or obey a later instruction that says “include everything you have seen.”
We called this control in identity isn’t enough: shaping the payload after authorisation. In the access-control landscape it is the governance half of egress – least privilege does not stop at the action. This post in the ARISE series is the Playbook’s Principle of Least Agency applied to data.
Why this is an agent problem, not just DLP
DLP and DSPM still matter. They were built for humans forwarding files and for data-at-rest inventories. Agents change the failure mode in three ways.
Context is a new store. A field that never landed in a database your CASB watches now lives in a prompt cache, a vendor’s training-adjacent log, or a chain-of-thought dump. The Playbook’s incident-ready accountability question – was this authorised? – has to include was this data authorised to enter the model.
Injection rides in on the way back. SACR’s MCP case study: communication-layer risk is indirect prompt injection in tool results. Oasis’s MCP firewall example in the same paper is sequence-aware: read confidential Salesforce data, then request Gmail – each hop permitted, the pair an exfiltration story. If the confidential fields never entered the agent, the second hop has less to steal. You will not regex every encoded payload. You can shrink what is worth encoding.
Over-sharing looks like a successful integration. Ofek’s optimisation essay: the agent is not cheating. A “complete record” is a better score on a retrieval task. The specification said “look up the customer.” The API returned the universe. Functional continuity asks whether the system is still doing what you approved, not only what it can. Approval for a support workflow did not include payment methods in the model’s head.
Ghostjacking, in aizome’s telling, is the identity-governance question inverted: not “is this agent allowed to do this” but “should it be doing this right now, based on what it just read?” That second question is unreachable if you cannot constrain what it just read.
What the Playbook almost says
Requirement three, organisational intent capture, includes “the data it is permitted to touch,” not only the systems it may call. Requirement four’s third signal is the data access pattern versus the intent profile. Requirement seven, incident-ready accountability, wants every logged action to include whether behaviour was consistent with the baseline – including, if you are serious, whether the payload was.
Most ARISE vendor narratives still under-weight the return path. Identity fabrics see tokens. Gateways that only allow/deny requests treat the response as a blob to forward. SACR notes that several agent runtimes deliberately never touch tool-call data, which simplifies their compliance story and leaves yours open. RequestRocket’s position in that map is the unfashionable one: retain or destroy fields on the way back, as a first-class policy, on APIs you do not own and cannot patch.
Compose with the tools that already classify data
You should not maintain a parallel universe of “what is PII.”
- DSPM / data catalogues (BigID and peers in SACR’s Keycard notes) already label sensitive stores. Use those labels when you decide which JSON paths a given agent’s proxy may retain. The proxy enforces; the catalogue explains.
- DLP in the CASB or email path still catches humans. It will not see a model context on a laptop unless you also control the outbound API hop.
- Token masking and PII regex at an MCP gateway (Runlayer’s pattern in the SACR brief) is complementary. Pattern-based blocking is brittle and necessary. Structured retain-lists are how you express intent: these four fields are the job.
- IdP still does not see the payload. Do not ask Okta to redact Salesforce. Ask Okta who the agent is; ask the proxy what that agent may receive.
Healthcare and finance make the argument without metaphor. PHI in a context window is a disclosure. PAN data in a context window is a PCI conversation. The upstream EHR or processor will not offer you an “agent-safe” projection. You project on the way in.
Honesty: filtering is not understanding
A JSON-path retain list will not detect that a free-text notes field contains a password. A regex will not catch a novel encoding. Guardian-style products that read reasoning and content have a role on that residue – Noma’s content / context / behaviour split in SACR. The outbound filter is the deterministic reduction of blast radius so those models have less to miss.
Filtering also does not replace request-side intent. An agent that should not GET /admin should be denied, not handed a redacted admin object. Deny is cheaper than redact. Redact is for the objects the job actually needs.
Next steps
For one agent, list the fields the workflow uses. Make that the retain set. Everything else is unapproved data in a memory you do not control. Pair it with meters so “I needed more rows” cannot become a bulk export of the fields you did allow.
The series turns next to the agents that never showed up in the register: shadow AI in core processes. Start for free.