> ## Documentation Index
> Fetch the complete documentation index at: https://intercept.promptphp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security notes

Intercept is a practical middleware layer for Laravel AI agents.

It helps reduce risk before prompts reach an AI provider, but it is not a complete security boundary on its own.

Use it as part of a layered AI safety strategy.

## Intercept is middleware, not magic

Intercept can inspect, redact, block, or modify prompts before they reach the provider.

It cannot guarantee that every unsafe input will be detected.

It cannot guarantee that every sensitive value will be found.

It cannot replace application-level authorization, validation, access control, or tool permission checks.

## Recommended layers

For production AI agents, combine Intercept with:

* server-side validation
* least-privilege tool access
* strict tool argument validation
* data minimisation
* provider safety controls
* audit logging
* rate limits and abuse detection
* human approval for high-risk actions
* clear user-facing error handling

## Prompt injection limits

Injection Guard uses heuristic pattern detection.

It is useful for common prompt injection attempts such as:

* ignoring previous instructions
* revealing hidden prompts
* bypassing system rules
* requesting internal instructions

It may miss:

* novel attacks
* subtle multi-turn attacks
* indirect prompt injection
* encoded attacks not covered by normalisation
* attacks hidden inside retrieved documents or tool results

Do not rely on prompt injection detection alone.

## PII detection limits

PII Redactor is deterministic and regex-based.

It is useful for structured values such as:

* email addresses
* phone numbers
* credit card-like values
* IP addresses
* API keys
* bearer tokens

It may miss:

* names
* postal addresses
* uncommon identifiers
* unusual phone formats
* secrets with unknown formats
* sensitive context that does not look like structured PII

It may also flag values that look sensitive but are not.

## What Intercept sees

Intercept middleware runs on the prompt as it enters the pipeline. That defines what it can and cannot inspect.

It sees:

* the prompt text sent to the agent
* edited tool arguments and rejection results supplied when resuming a paused run
* the tool calls the model proposes for approval, with [Tool Approval Guard](/middleware/tool-approval-guard) installed

It does not see:

* tool results returned to the model mid-run
* attachments sent alongside the prompt
* prior conversation history replayed from a conversation store
* the model's response text

This matters most for indirect prompt injection. If a tool fetches a web page, reads a document, or queries a record that contains injected instructions, that content is handed to the model without passing through Intercept.

Tool Approval Guard narrows that gap but does not close it. It inspects what the model *proposed* after reading poisoned content, which is where the damage usually surfaces, but it cannot inspect the poisoned content itself. It also only applies to tools that are approval-gated. A tool that runs without approval is never inspected.

Guard those surfaces separately:

* validate and constrain tool arguments server-side
* treat tool results as untrusted input in your own code
* scope tool permissions to the acting user
* require human approval for destructive actions
* review retrieved documents before they enter agent context

## Tool approval resumes

When a paused run is resumed with `Decisions`, the prompt text is empty. The new content is what a human supplied while resolving the pending tool calls, and Intercept scans it.

Two limits are worth knowing.

Resumed prompts are immutable, because a paused turn must replay verbatim against the provider that recorded it. Actions that rewrite the prompt cannot apply, so `redact`, `mask`, `sanitize`, and `warn` degrade to logging on this path. Only blocking genuinely stops the content.

If your threat model requires that PII never reaches the provider, do not rely on `redact` alone. Add the relevant entity types to `block_entities`, or validate the edited arguments in your approval flow before they are submitted.

## Safe user-facing errors

When a prompt is blocked, return a simple message.

Good:

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Please remove sensitive information and try again.
```

Good:

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Your message could not be processed because it appears to contain unsafe prompt instructions.
```

Avoid:

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Your prompt matched /ignore previous instructions/i.
```

Avoid:

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Your API key sk_live_... was detected.
```

Do not expose internal patterns, raw values, or detection details to users.

## Best practice checklist

Before launching a public AI agent:

* install only the middleware you need
* publish and review config
* decide which actions to use per environment
* catch middleware exceptions
* use safe user-facing error messages
* avoid raw prompt logging
* validate tool calls server-side
* minimise prompt context
* test with realistic unsafe prompts
* review false positives before blocking aggressively
