Secrets and data boundaries

By the end, you can

• Explain what "the agent can read it" implies once a credential or personal-data file is inside an agent's reach, including how untrusted content can try to exploit that reach (LA-3).
• Apply environment separation to keep credentials and personal data out of an agent's default reach, using least-privilege access as the deciding principle (LA-3).

Before you start

This is Module 3, Lesson 2 of the Local AI Agents course. It assumes the previous lesson's dedicated, disposable workspace, Module 1's data boundary, and Module 2 Lesson 1's sensitivity constraint — what must never be included in a task's input, even when it is technically present in the source. This lesson takes that sensitivity constraint and applies it specifically to credentials, API keys and personal data, and to what changes once an agent's reach actually includes them.

"The agent can read it" is a bigger claim than it sounds

It is easy to treat "the agent can technically read this file" as a minor detail, especially when the file just happens to sit in the workspace and the agent was never told to look at it. That framing understates what reach actually means. Once a credential or a personal-data file is inside an agent's reach, it is available to every tool call the agent makes, every trace or log the run produces, and — if the agent processes any content it did not fully control — every attempt embedded in that content to get the agent to act on it.

OWASP's guidance on sensitive information disclosure names exactly the categories this covers: "personal identifiable information (PII), financial details, health records, confidential business data, security credentials, and legal documents." None of these need to be the task's subject to become a problem — they only need to be reachable from where the agent runs. Reach, not intent, is what "the agent can read it" describes.

• What "reach" includes in practice: environment variables available to the agent's process, files anywhere inside its workspace tree, configuration files with embedded tokens, shell history, and anything a granted tool can open on the agent's behalf.
• None of these have to be the task's declared input to be reachable. That is exactly what Lesson 1's dedicated workspace exists to prevent — but the workspace boundary is about location; this lesson is about the credential and data items themselves, wherever they sit.

Keep credentials out of reach by default — environment separation

The safest version of a credential is one the agent's workspace never contains at all. OWASP's guidance states the underlying principle plainly: "Limit access to sensitive data based on the principle of least privilege. Only grant access to data that is necessary for the specific user or process," and separately recommends that operators "limit model access to external data sources, and ensure runtime data orchestration is securely managed to avoid unintended data leakage."

Applied to a local agent, that principle becomes environment separation: the agent's runtime does not automatically inherit every credential the operator's own account happens to have. Each tool the agent uses is issued its own narrowly scoped credential — one that can do exactly what that tool needs and nothing more — rather than the agent's environment quietly holding the operator's full set of ambient secrets, "in case something needs them later." This is Module 1 Lesson 3's tool-grant principle again, extended from capability to authentication: a tool description that is scoped narrowly is undone by a credential that is scoped broadly.

A light, honest seed: untrusted content can try to move data across this boundary

This module is not the place for a full treatment of prompt injection — that is a deeper subject than a safe-local-setup module can cover, and this course does not yet have a later module dedicated to defending against it. What belongs here is the honest, narrow point: if an agent reads content it did not fully control — a downloaded file, a scraped page, an email — as part of its task, that content can contain instructions aimed at the agent, not at the person reading it.

OWASP's guidance on prompt injection describes this directly: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files," and documents a concrete exfiltration pattern where a manipulated response causes "the LLM to insert an image linking to a URL, leading to exfiltration of the private conversation." The mechanism there is an outbound network action, not a filesystem one — a detail the next lesson picks up directly. For this lesson, the point is narrower still: an agent that genuinely cannot read a credential cannot be talked into leaking it, by injected content or otherwise. Keeping secrets out of reach is not only an access-control habit; it removes a target that untrusted content might otherwise try to reach for.

A worked example: a coding agent and a `.env` file

A local coding agent works inside a project repository to review and refactor application code. The repository's `.env` file holds a live database password and two third-party API keys.

Version A gives the agent's workspace full read access to the repository as it stands, `.env` included, because excluding one file felt like unnecessary setup. The agent never needed the real credential values to review or refactor code that only references environment-variable names — but it can now read them anyway, and so can anything the agent's context, logs or traces retain.

Version B excludes `.env` (and any other credential store) from the agent's workspace entirely, or replaces it with a placeholder file containing only variable names and no real values. The coding task is unaffected: reviewing and refactoring code that references `DATABASE_PASSWORD` does not require knowing what that password actually is. The real credentials stay where the running application reads them from, a system the agent's task never touches.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. LLM02:2025 Sensitive Information Disclosure — OWASP Gen AI Security Project. Recommends limiting access to sensitive data on a least-privilege basis and securely managing runtime data orchestration to avoid unintended leakage.
2. LLM02:2025 Sensitive Information Disclosure — OWASP Gen AI Security Project. Names personal identifiable information, financial details, health records, confidential business data, security credentials and legal documents as the categories that need a data boundary.
3. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project. Documents indirect prompt injection from external content such as websites or files, and an exfiltration example where a crafted response causes data to leave via an outbound link.