The boundary between policy and execution starts to collapse. If system prompts contain identity, scope, tools and internal references, a successful extraction attack can reveal the same facts defenders rely on to govern the agent. That creates a shadow control plane inside the prompt itself, which is difficult to audit and easy to leak.
Why the prompt becomes a control plane when it carries identity and tools
System prompts are supposed to define behaviour, not hold the facts that govern access. Once identity, scope, tool names, or internal references are embedded there, the prompt stops being a pure policy layer and starts carrying operational control data. That makes the prompt itself part of the attack surface, especially when the model can be induced to reveal or paraphrase it.
This is why prompt leakage is not just an information disclosure issue. It can expose the same authority cues defenders rely on to route requests, limit tool use, or distinguish one role from another. OWASP LLM07 System Prompt Leakage Guide is useful here because it treats prompt content as something that should not be carrying secrets, roles, or limits that need stronger enforcement elsewhere.
When the prompt contains those details, the model is effectively holding a shadow control plane. It may still answer correctly, but the governance boundary becomes harder to inspect, harder to rotate, and easier to leak through extraction attacks, indirect prompt injection, or careless logging.
What specifically fails when policy and execution are mixed together
The first failure is separation of duties. Policy language and executable context should not be co-located if a prompt can be queried, echoed, or extracted. If the prompt includes the identity of the agent, its scope, and its tool catalog, the attacker only needs one successful disclosure path to learn how the system is allowed to behave.
The second failure is control durability. Prompted controls are brittle because they depend on the model preserving and interpreting them correctly under pressure. External guardrails, server-side authorisation, and tool gating are much easier to enforce than instructions hidden inside the very text that an adversary is trying to manipulate. The safest design keeps identity and tool permissions out of the prompt and moves them into the application layer.
The third failure is auditability. If the effective policy lives in a long system prompt, teams often cannot tell which parts are normative policy, which parts are operational configuration, and which parts are just convenience text. LLM Security Guide is a useful reference because it frames system prompt extraction, data leakage, and output handling as separate hardening problems rather than one vague prompt issue.
Why exposed identity data raises the blast radius
Identity details in a prompt are not always sensitive on their own, but they become sensitive when they reveal which tools, permissions, or internal references the agent can reach. That can help an attacker pivot from curiosity to misuse, especially if the same prompt also hints at escalation paths, hidden tool names, or internal routing logic. Identity Convergence Guide helps frame why those boundaries matter when identity, privilege, and tool access are collapsed into one operating surface.
Exposure also matters because prompt content tends to be reused. A single prompt template may be deployed across environments, assistants, or workflows, so one disclosure can reveal a whole pattern of control design. That is where the damage grows from a single leak to a reusable governance weakness: the attacker learns how the system thinks it is constrained, then looks for ways to bypass those constraints in another session or environment.
When tool data is present, the prompt may also reveal downstream capability mapping, which makes abuse easier even without full compromise. An attacker does not always need secret values; knowing which tool exists, what it is called, and what role it is meant to play can be enough to steer a model into unsafe action. OWASP Top 10 for LLM Applications Guide is relevant because it places system prompt leakage alongside broader LLM abuse patterns that turn hidden configuration into exploitable knowledge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Identity and tool data in prompts can enable misuse of agent authority. |
| ASI02 — Tool Misuse | Tool names and scopes in prompts can be abused to steer unsafe tool use. | |
| Recommendation — Separate tool authorisation from prompt content and enforce least privilege server-side. Constrain tool invocation in application logic rather than relying on prompt instructions. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | System prompts that embed identity and tool data can leak operational secrets. |
| NHI-10 — Human Use of NHI | Prompt disclosure can expose how humans and systems interact with non-human identities. | |
| Recommendation — Remove sensitive identity and scope data from prompts and store it outside model-visible text. Limit prompt details that reveal human workflows around machine credentials and tool access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Tool and service access for automated actors depends on strong non-human authentication. |
| Recommendation — Authenticate service and agent access outside the prompt and bind it to enforced trust decisions. | ||
Practitioner Guidance
What to prioritise: Keep identity, scope, tool inventories, and internal references out of the system prompt unless they are harmless to disclose. If the information would help an attacker understand tool reach or control boundaries, treat it as application state, not prompt content.
What to verify: Check where the effective policy actually lives. A good design makes the prompt descriptive and the enforcement server-side, with tool authorisation, routing, and logging implemented outside model-visible text.
Common mistake: Teams often think a prompt is safe because it is not an API key or password. In practice, identity and tool metadata can still act like governance material because they tell an attacker what the assistant can touch and how it is constrained.
Practitioner takeaway: If the prompt is carrying the facts that enforce the boundary, the boundary is already too soft; move those facts into controls that do not depend on model secrecy.
Related resources from NHI Mgmt Group
- How should security teams handle system prompts that may contain sensitive data?
- What breaks when access checks are embedded only in system prompts or tool descriptions for AI agents?
- What breaks when system prompts contain secrets or access rules?
- Why do AI agents make non-human identity governance harder?