Promptective journal / Guide
Designing the AI security boundary
Controls for prompts, data, outputs and tools.
Production LLM security should ask what can cross the boundary between an AI system and the organisation. Prompts can carry secrets to a provider, retrieved documents can carry instructions, output can expose data and tool calls can trigger real actions.
A four-zone trust model
Scroll horizontally to compare columns
| Zone | Examples | Default trust |
|---|---|---|
| Control plane | System instructions, policy, permissions, identity | Trusted and tightly managed |
| User plane | Prompts, uploads, pasted code | Untrusted input |
| Knowledge plane | Pages, tickets, documents, tool results | Untrusted data |
| Action plane | Output, tool arguments, API requests | Untrusted until validated |
Text does not become trusted because it arrived through a trusted component. A retrieved document remains external content, and a model-generated argument remains a proposed action.
Four zones, explicit trust
Control plane
Managed policy, identity, permissions and system instructions.
User plane
Prompts, files and pasted content from the person using the system.
Knowledge plane
Retrieved documents, web content, search results and tool output.
Action plane
Model responses, tool arguments, writes and external effects.
Normalise and preserve provenance
Convert interactions into typed parts such as system text, user text, retrieval, code, tool calls and tool results. Attach identity, application, model, environment and action risk. This common vocabulary makes detection and policy decisions explainable without storing whole conversations.
Bound request size, nesting, arrays and argument complexity before expensive parsing. Keep policy outside user-editable context, pass only required fields and treat retrieval and tool results as hostile input on the next turn. Delimiters help interpretation but cannot authorise an action.
Inspect both directions
Scroll horizontally to compare columns
| Boundary | Checks | Response |
|---|---|---|
| User to model | Secrets, personal data, injection, size | Warn, redact or block |
| Retrieval to model | Provenance, encoding, scope | Quarantine, omit or annotate |
| Model to user | Sensitive or unsafe content, unsupported claims | Redact, block or review |
| Model to tool | Schema, authority, scope, risk and rate | Allow, approve or deny |
Detection informs enforcement. A confirmed credential can be redacted before forwarding. A destructive tool call from untrusted context should be denied regardless of the model's confidence.
The prompt injection examples and defences guide shows how user input, retrieved documents and tool output can cross these trust boundaries.
Four inspection points around one model
User to model
Secrets, personal data, injection signals and oversized input.
Retrieval to model
Provenance, suspicious instructions, encoding and scope.
Model to user
Sensitive data, unsafe content and prompt leakage.
Model to tool
Schema, authorisation, resource scope and action risk.
Keep tools narrow
Give each tool a typed operation, permitted resources, rate limit and approval rule. Validate arguments against a strict schema, resolve resource identifiers on the server and check the caller's entitlement outside the model. Bind approval to the exact tool, arguments, identity and expiry.
Destructive and privileged actions need an allowlist plus independently enforced approval or change control. These barriers limit impact when a model, source or session is compromised.
Make actions boring and explicit
Name the operation
Use a specific tool and distinguish read, write, delete and execute.
Validate arguments
Apply a strict schema and resolve resource identifiers on the server.
Bind authority
Check identity, resource scope, environment, rate and action risk.
Enforce outcome
Allow, request exact approval or deny before execution.
Keep evidence content-minimised
Routine records can include trace, tenant, identity, application, model, policy and detector versions, reason codes, action risk, outcome, content-part hashes, sizes and delivery state. Raw content should require review, access controls, encryption, retention limits and deletion.
The record should explain what happened, why the decision occurred and which policy was active without becoming a transcript archive. Retained metadata can support controlled replay with synthetic content without recovering the original prompt or response.
Roll out by impact
- Inventory providers, models, applications, tools, identities and environments.
- Observe payloads, findings, tool use and false positives.
- Block high-confidence, high-impact cases such as credentials and unauthorised tools.
- Redact recoverable sensitive data.
- Require exact-action approval for irreversible actions.
- Define behaviour for policy outages, detector timeouts and malformed output.
- Review exceptions, missed detections and policy drift.
A low-risk drafting assistant may use a verified policy cache during an outage. Payment and deletion tools should fail closed. Document the choice per surface.
Move from visibility to enforcement
Inventory
Map providers, applications, identities, tools and environments.
Observe
Measure real paths, findings, latency and exceptions.
Enforce
Block clear high-impact cases and redact recoverable exposures.
Approve
Add exact human review for irreversible operations.
Tune
Test failures and review false positives, misses and policy drift.
Final checklist
- Every interaction carries identity, application, model and environment.
- Prompts, retrieval, output and tools retain provenance.
- Sizes and complexity are bounded before inspection.
- Input and output checks use stable reason codes.
- Tool authority is deterministic and model-independent.
- Privileged actions receive stronger controls than reads.
- Routine telemetry stores metadata and hashes, excluding raw content.
- Outage behaviour is explicit per surface.
- Policies, detectors and exceptions are versioned.
- Tests cover injection, leakage and tool misuse.
For risk mapping, testing, monitoring and incident response, use the LLM security best-practices guide.
Security review
Map policy to the AI paths your team uses.
See where Promptective can apply organisation policy and record content-minimised evidence.
Map your AI workflows