Sensitive data and secrets in agent context
Definition
Sensitive data in agent context is any regulated, confidential or credential material that reaches an agent's prompt, tool responses, transcripts, memory or logs.
The discipline is to decide what may enter the context, keep secrets out of configuration entirely, and retain the resulting copies deliberately.
Agents create copies of data in places applications never did. A prompt is a copy, a transcript is a copy, a tool response is a copy, and a memory store is a copy that outlives the session. Data governance that stops at the database has not been extended to any of them.
Why does sensitive data in agent context matter now?
Agents are being pointed at production systems. In the 2026 Stack Overflow survey, 20% of respondents used AI for deploying or operating production systems (Stack Overflow 2026). The data an agent can read during those tasks is the same data an attacker wants.
The credentials in that path are the least governed part. In a survey of 5,200 open-source MCP servers, 88% required credentials, 53% relied on long-lived static secrets, only 8.5% used OAuth and 79% passed API keys through environment variables (State of MCP Server Security 2025, Astrix). On an endpoint, that is a file in a project directory with a durable key inside.
The best-documented agent disclosure was not a database breach. EchoLeak, tracked as CVE-2025-32711 with a CVSS of 9.3, was a zero-click prompt-injection information disclosure in Microsoft 365 Copilot (NVD). The data left through the agent's own capabilities rather than through a broken perimeter.
Tool-level attacks show the same shape at smaller scale. A poisoned tool description caused an agent to read ~/.ssh/id_rsa and its own configuration and then exfiltrate both (Invariant Labs). In a study of 20 agents and 45 live servers, o1-mini was steered by a poisoned tool 72.8% of the time, and no model refused more than 3% of attacks (MCPTox, arXiv:2508.14925).
How exposed is your setup? Compass walks through how your agents handle sensitive data and credentials and returns a starting risk read: compass.alyria.ai.
How is agent context different from application data?
An application stores data where its design says. An agent copies data wherever a prompt, a response or a log happens to put it.
| Location | Who can read it | Retention in practice | Control that works |
|---|---|---|---|
| Prompt and context window | The model endpoint, the session | Seconds to hours | Classification enforced where data enters |
| Tool response | The agent, the transcript | Session plus logs | Field-level response limits |
| Transcript | Local disk, vendor console, SIEM | Weeks to indefinitely | Retention policy, access control, redaction |
| Agent memory or vector store | Future sessions, other users | Indefinite unless managed | Separate classification and deletion path |
| Logs and traces | Security and platform teams | Weeks to years | Structured logging without payloads |
| Secrets in config | Anyone with file access | Until rotated | Broker leases, remove keys |
| Model provider retention | The provider, per contract | Per contract | Contract terms, regional endpoints |
In practice: Every row is a copy. The control question is which copies are allowed to exist and for how long.
What are the main risks?
Secrets in configuration
A key in a config file has no expiry, no audience and no attribution. It also travels: dotfiles repositories, backups, screenshots, support tickets. This is the risk least affected by model choice and most affected by engineering hygiene.
Over-sharing through tool responses
A tool built to answer "does this customer have an open order" often returns the whole customer record. The agent then holds fields it never needed, and they enter the context, the transcript and any summary the agent writes.
In practice: count the copies before you argue about the controls. A prompt, a tool response, a transcript, a memory store and a log are five places the same record can exist.
Credentials in shell history and dotfiles
Not every secret leak is a prompt problem. Agents run shell commands, and shell history, terminal scrollback and dotfiles are ordinary places for a key to end up. A command that exports a token for one task leaves it in a history file that outlives the task and that the next agent, or the next person, can read.
Rotating the key is the fix for the leak and not for the pattern. The pattern is fixed by issuing a lease for the task so there is nothing durable to leave behind, and by keeping credential paths out of the agent's read scope so history and dotfiles are not reachable at all.
Transcript spill
Sessions are recorded for debugging and for evidence. The same transcript that proves what an agent did also contains the data it read, sometimes with credentials included. Retention without classification produces a long-lived copy of everything.
Redaction that fails on derived values
Redaction works on fields. It struggles with combinations: a name plus a postcode plus a date of birth identifies a person without any single field being sensitive. Agents summarise and infer, which is exactly the operation that reconstructs identifiers from safe-looking inputs.
Memory and context poisoning
Once an agent writes to memory, the write outlives the session and becomes an instruction channel for later turns. Poisoned memory is both a data integrity problem and a disclosure risk, because the poisoning arrives with the data.
Provider and region exposure
A prompt sent to a hosted model crosses a boundary defined by contract, not by your network. Where the data is regulated, the endpoint, the region and the retention terms are part of the control set.
Logs that were never designed for this
Application logs were designed to record requests, not conversations. Payload logging switched on for troubleshooting stays on, and it becomes the largest unclassified copy in the estate.
How to implement data controls for agent context
The controls are ordered from classification to retention, because each step depends on the previous one.
1. Classify data per agent, not per company
Take the existing classification scheme and answer one question per agent: which classes may this agent read? Record the answer with the agent's policy. A scheme that stops at the database has not been applied to the agent.
Tip: Start with three classes. Public, internal, and restricted is enough to make decisions, and it maps to most schemes without a translation project.
2. Enforce at the point where data enters
Decide at the tool response, not only at the prompt. If a tool returns a whole record, the agent has already received data outside its class before any prompt filter runs.
3. Limit tool responses to the fields needed
The narrowest tool is the strongest control. A support tool that returns six named fields cannot over-share, whatever the agent asks for. This is also the cheapest change to make, because it is a server-side change in code the team already owns.
Tip: Review new tools by their response schema. The schema is the data scope, expressed in a form a reviewer can read.
4. Broker secrets and remove keys from files
Short-lived leases, scoped to the task, injected at the moment of use and bound to the device. Where a key must exist, give it an owner, an audience, a rotation schedule and a detection rule.
5. Redact where content cannot be narrowed
Where a document must be read, redact at the boundary and log the redaction. Keep the rule set versioned, because redaction rules drift and an unversioned rule cannot be audited.
6. Set retention per artefact
Transcripts, memories, logs and exports each get a period and an owner. Memory needs its own rule, because it outlives the session that created it.
Tip: If nobody can name the retention period for transcripts, the real period is forever. That answer usually triggers a decision.
7. Keep payloads out of logs
Log decisions, not content. A decision record needs the tool, the arguments that determine policy, the outcome and the reason. It rarely needs the document body.
8. Test the disclosure path
Plant a restricted value in a document the agent can read and confirm where it ends up: the context, the transcript, the log, a send attempt. Then confirm the send is refused. This test finds more than any policy review.
Where data controls apply in the lifecycle
Design
Choose the data classes, the tool response shape and the retention model. All three are design decisions that are expensive to change later.
Note: A design that lets tools return whole records will leak data through every later control, because the copy already exists by the time policy sees it.
Development
Keep secrets out of the repository and out of environment variables that outlive a deployment. Request credentials through the broker in code, so the local path and the production path are the same shape.
Pre-deployment testing
Test the disclosure path with real data classes and a hostile document. Confirm the denial and the record, and confirm that transcripts do not contain the restricted values.
Note: A redaction test that passes on fields and fails on combinations has tested the easy case.
Deployment
Confirm transcript access control, memory retention and log payload settings before the agent serves a real request. These are configuration defaults that nobody revisits.
Runtime
Data classification is enforced where data enters, secrets are leased, and sends carrying restricted data are refused or held. Every one of those decisions is recorded.
Continuous monitoring
Watch for new tools with wide responses, new data sources, retention exceptions and any memory store growing without a rule.
Note: A tool added with a wide response schema is a data scope change, even though it arrives as a feature.
Decommissioning
Delete the memory store, export and retain transcripts for the required period, revoke the leases and remove stored keys. Deletion is part of the record, not an afterthought.
The takeaway: Agent data risk is a copy problem. Fewer copies, narrower copies, shorter retention and recorded decisions are the whole strategy.
Worked example: a health insurer's member data
A health insurer deploys an agent to help service representatives answer member questions. It reads member records, policy documents and claim notes, and drafts replies.
The starting scope. The agent's tools return full member records because that is what the existing API returns. Within a week the transcript store holds full records for 40,000 conversations, including diagnosis codes from claim notes.
The narrowing. The member tool is rewritten to return eight named fields, and the claim notes tool returns a summary flag rather than free text. The agent's answers stay as good, because it never used the extra fields. The transcript store stops accumulating the widest data.
The secrets. Three MCP servers held API keys in environment variables, one with write scope on the claims system. All three move to short-lived leases with a read-only scope. The write scope is removed entirely; the agent now drafts changes for a representative to apply.
The redaction. Diagnosis codes are classified restricted. Where a claim note must be read for context, codes are redacted at the boundary and the redaction is recorded with the rule version. A test that plants a code in a note confirms the copy does not appear in the transcript.
The retention. Transcripts move to 30 days with access controlled by role, and the memory store is disabled for the pilot because nobody could name a retention period for it.
The incident. In month two, a member's email contains an instruction to include claim details in a reply. The agent composes the reply with a diagnosis summary. The send is refused because the payload contains restricted data read in the same session, and the representative sees the draft rather than the member. The record shows the read, the attempted send and the refusal.
The audit. A privacy review asks what member data the agent could access in the first quarter. The answer comes from the register, the tool schemas and the transcript classification, and the finding is four tools that returned more than needed, three of which are now narrowed.
How standards and regulations influence data in agent context
| Framework | Primary focus | Relevance to agent data |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, Manage | Expects data flows and affected parties to be mapped in context |
| ISO/IEC 42001 | AI management system with documented controls | Requires documented data handling and supplier terms |
| ISO/IEC 42005 | AI system impact assessment | Structures the assessment of disclosure impact |
| EU AI Act | Obligations by risk class, including logging and transparency | Sets documentation and oversight duties for high-risk systems |
| OWASP Top 10 for LLM Applications | LLM02 sensitive information disclosure, LLM06 excessive agency | The application-level view of the same failures |
| OWASP Agentic Top 10 | ASI03 identity abuse, ASI06 memory poisoning | Explains how data and instructions mix in an agent |
| OWASP MCP Top 10 (beta) | MCP01 token mismanagement, MCP10 context over-sharing | The tool-layer controls |
| SOC 2 | Confidentiality, access control, monitoring | Expects data to be classified, limited and evidenced |
Further reading: The lethal trifecta for why these copies become exfiltration material, Non-human identity and agent identity for the credential side, and AI coding agent security for the developer-machine version.
How Alyria handles it
Alyria enforces the data decision at the point where it can still be made. Beacon routes each agent's tool and network calls through a local policy service, and Lyra evaluates the information-flow rule: which data class may this agent read, and may this call carry it out.
That rule is what turns a policy sentence into a control. A send carrying restricted data read in the same session is refused or held, without needing to recognise the injection that produced it. The decision is recorded with the data class, so the audit answer does not depend on a transcript review.
Umbra keeps credentials out of context entirely. Leases are issued at the moment of use, sealed to device hardware keys Alyria never holds, so a config file copied to a shared drive carries nothing usable. Spectra exports signed, chained decisions to Alyria Cloud or your own SIEM, and the export records decisions rather than payloads.
Free Agent Exposure Report: see which data sources and credentials your agents can reach today: alyria.ai/agent-exposure-report.
The docs cover information-flow policy, and the platform overview explains how the modules fit together.
Frequently asked questions
- Is redaction before the prompt enough?
- It helps and it is not sufficient. Redaction fails on derived values, on data returned by tools after the prompt and on identifiers reconstructed from several fields. Enforcement has to also decide which data a tool may return and where the result may go.
- Where do agents leak data most often?
- In tool responses and transcripts rather than in prompts. A tool that returns whole records to answer one question hands the agent far more than it needs, and that copy then lives in the session, the log and sometimes a vector store.
- Should agent transcripts be retained?
- Yes, for a defined period and under access control, because the transcript is the evidence for what the agent did. The mistake is unlimited retention in a tool nobody governs, not retention itself.
- How do you keep secrets out of agent configs?
- Broker them. A short-lived lease issued at the moment of use and scoped to the task removes the need for a key in a config file. Where brokering is impossible, the key needs an owner, an audience restriction, rotation and detection for unexpected use.
- Does using a private model endpoint solve the data problem?
- It changes one variable: who else can read the prompt. It does nothing about what the agent reads, what it stores, what it sends or how long it keeps a copy. A disclosure through the agent itself is the failure to design against.
- What is the smallest useful control set?
- Define data classes per agent, enforce them where data enters the context, broker secrets, restrict tool responses to the fields needed, and set transcript retention with access control. Five controls cover most realistic paths.
- How do memory features change this?
- They add a new store with a new retention period and a new poisoning surface. Anything written to memory outlives the session, which means the data classification and the retention rule have to apply to memory separately.