Skip to main content
Product updates and release notes for Intercept.
PatchSecurity
v0.3.1
Narrowed the Tool Approval Guard defaults. If you installed v0.3.0, upgrade.If you published config/intercept.php, this fix does not reach you automatically. Update tool_approval_guard.entities to [‘credit_card’, ‘api_key’, ‘bearer_token’]and settool_approval_guard.scan_injectiontofalse` by hand.The defaults were derived from the PII Redactor entity list, which treats an email address as sensitive. That is right for a prompt and wrong for a proposed tool argument, where the address is usually the function signature. With the default block action, any agent owning a mail, SMS or HTTP tool had its legitimate calls blocked outright. Exfiltration is about destination, not presence.
  • entities now defaults to credit_card, api_key and bearer_token. email, phone, url, ip_address and mac_address are still supported, but opt-in.
  • scan_injection now defaults to false. Prose written for a human reader routinely matches the patterns. Enable it when a proposed argument feeds another model or agent rather than a person.
block_entities is unchanged, so the security floor stays where it was, and every change here loosens a default — nothing that worked on v0.3.0 stops working.Also documented a sharp edge that was always present: action: 'log' is not observe-only on its own, because block_entities stops the run whatever the action is set to. Pair it with blockEntities: [] for a dry run.
ReleaseSecurity
v0.3.0
Added promptphp/intercept-tool-approval-guard, a new middleware that inspects the tool calls an agent proposes while pausing for human approval, before they are surfaced for review.Intercept has always inspected what goes out. It never saw what comes back in — tool results, retrieved documents, and conversation history do not pass through the middleware pipeline, and that is exactly where indirect prompt injection lives.When an agent is manipulated by content Intercept never saw, the damage almost always surfaces as a tool call:
Tool Approval Guard inspects those proposed calls. It checks three things:
  • whether the tool is permitted at all, via allow and deny lists
  • whether an argument carries secret-like data such as a card number, API key or bearer token
  • whether an argument matches a prompt injection pattern, which signals the model was manipulated
In the example above it is the card number that flags the call, not the address — a mail tool is expected to carry an email address.It reuses the detectors and patterns from PII Redactor and Injection Guard rather than maintaining a second copy, so it inherits their behaviour exactly.This release also closes an asymmetry shipped in v0.2.0: Intercept scanned what a human edited when resolving a paused run, but trusted whatever the model proposed.The middleware only acts when a run pauses for approval, so adding it is safe even before you adopt human-in-the-loop.
ReleaseSecurity
v0.2.0
Added tool approval decision scanning to PromptInjectionGuard and PIIRedactor.When an agent pauses for tool approval, the run is resumed by passing Decisions back to the agent instead of a new prompt. A resumed prompt carries no prompt text, so both middleware previously reported clean while the content a human supplied on the way through reached the AI provider unscanned.Both middleware now scan that content:
  • edited tool arguments, from Decision::edit()
  • rejection results, from Decision::reject()
A paused turn must replay verbatim against the provider that recorded it, so resumed prompts cannot be rewritten. The redact, mask, sanitize, and warn actions therefore degrade to logging on this path, recorded in logs as degraded_from. Blocked entities and the block action still stop the run.Scanning is enabled by default and can be turned off per middleware with scan_approval_decisions.The documentation now also states plainly what Intercept can and cannot inspect, since tool results, attachments, and conversation history never pass through the middleware pipeline.
ReleaseSecurityFix
v0.1.9
Fixed PromptInjectionGuard failing to detect several of the most common prompt injection phrasings.These were not matched by any built-in pattern:
  • ignore all previous instructions
  • disregard all previous instructions
  • ignore the previous instructions
  • disregard the previous instructions
  • ignore all previous prompts
The ignore and disregard patterns required the noun to follow the qualifier immediately, so a phrase like ignore all previous instructions fell between them. They now use the same structure the forget pattern already had.If you are on an earlier version and rely on PromptInjectionGuard, upgrade.One thing to check when upgrading: the built-in pattern strings appear in log context and are passed to custom callbacks as $detection['pattern']. Anything asserting on the exact pattern text for ignore or disregard needs updating.
Release
v0.1.8
Added support for PHP 8.3 across middleware collection.
ReleasePII Redaction
v0.1.7
Added support for all versions of laravel/ai.Added support for detecting URLs in PIIRedactor.URLs are now treated like other supported PII entities and can be
  • redacted
  • masked
  • logged
  • blocked
Documentation has also been updated to include the new supported entity type and usage examples.
ReleasePII Redaction
v0.1.6
Added support for detecting MAC addresses in PIIRedactor.MAC addresses are now treated like other supported PII entities and can be
  • redacted
  • masked
  • logged
  • blocked
Documentation has also been updated to include the new supported entity type and usage examples.
ReleaseSecurityCommunity
v0.1.5
Hardened the built-in prompt injection detection patterns in PromptInjectionGuard to improve protection against common prompt injection attempts.Also improved the project documentation by adding contribution guidelines and updating the roadmap to help developers contribute consistently to Intercept.
ReleaseDXDocs
v0.1.4
Added a shared InterceptException base exception in the Support package.Middleware-specific exceptions now extend the shared exception:
  • PromptInjectionGuardException
  • PIIRedactorException
This lets applications catch one shared Intercept exception when they want simpler error handling, while still keeping middleware-specific exceptions available for more granular control.Also added documentation for handling blocked prompts and improved the release title generation used across repositories.
ReleaseFix
v0.1.3
Fixed Laravel package discovery when installing the root promptphp/intercept meta package.The shared Support service provider is now auto-discovered correctly, which fixes:
returning no publishable resources after installing the meta package.This release also improved release tooling so the root package and split packages can stay version-aligned.
ReleaseFix
v0.1.2
Added the missing promptphp/intercept-support split package release.Also added the missing test namespace mapping for the Support package and ensured Support is included in validation, mirror creation, metadata sync, splitting, and release workflows.
Release
v0.1.1
Release housekeeping for the initial split package publishing flow.
Initial release
v0.1.0
Initial public release of Intercept.This release introduced Intercept as a modular middleware collection for Laravel AI agents.It included:
  • promptphp/intercept
  • promptphp/intercept-support
  • promptphp/intercept-injection-guard
  • promptphp/intercept-pii-redactor
It also added shared configuration through config/intercept.php, the intercept-config publish tag, prompt injection detection, PII redaction, safe logging, package documentation, Pest tests, and the split-package monorepo structure.