AI Agent SecurityKnow what your AI agents are allowed to touch.
For a local MCP server started behind the RedactWall guard, each tool call is authorized before the upstream server runs and its result is checked before the model receives it. A tool the assistant reaches by another route is outside that guard.
Routed through guard before run
What that looks like in practice
A coding assistant routed through RedactWall reaches for a tool nobody approved
The call is refused, and you can see it was attempted.
A tool result returns through the RedactWall guard with customer data
Checked before the model reads it.
An engineer adds an AI tool on an enrolled workstation
It appears as a finding, not as something you approved.
An enrolled workstation has not completed its declared check
It is reported as unchecked, never as clean.
What you get
Refused before it runs
A tool call routed through the RedactWall guard is allowed or refused before the upstream MCP server runs.
Yours, versus theirs
Declarations reported by enrolled workstations are separated into what your operators set up and what a staff member wrote.
Approvals you can show
Each decision lands on a record your own team can check, next to every other path.
Review deployment requirements for agent tooling
Agent-tooling rollout is outside the proposed first pilot. Review what this broader product surface supports before planning a separate deployment. See Coverage for this surface’s level and Integrations for the assistants it works with.
Explore the guided pilot
MCP and coding-agent workflows are part of the broader implementation. The proposed first pilot covers the browser and gateway paths below.
- Only calls routed through the guard are governed
- Bypass paths remain outside the guard
- Governed calls and results are recorded