Governing autonomous agents in Warp - tool call interception + audit trail via SupraWall (MCP adapter)

[wiserautomation]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates

• - [x] I have searched Warp docs and my feature is not there

• [ ]

• ### Describe the solution you'd like?

• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.

• [ ]

• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?

• [ ]

• ### The Governance Gap

• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.

• [ ]

• ### Deterministic Tool Gating (MCP)

• We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.

• [ ]

• ```python

• # pip install suprawall

• from suprawall import secure_agent, Policy

• [ ]

• # Define deterministic constraints

• policy = Policy(

• max_daily_usd=10.00,

• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands

• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review

• )

• [ ]

• # Wrap the Warp agent via MCP

• agent = secure_agent(warp_claude_code_agent, policy=policy)

• [ ]

• # Execution is now gated by the SupraWall perimeter

• await agent.run("Refactor the production database schema.")

• ```

• [ ]

• ### What it produces:

• * Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.

• * RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.

• * Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.

• [ ]

• ### Open Question

• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?

• [ ]

• Links:

• * GitHub: github.com/wiserautomation/SupraWall

• * Docs: supra-wall.com

• [ ]

• ### Is your feature request related to a problem? Please describe.

• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.

• [ ]

• ### Operating system (OS)

• macOS

• [ ]

• ### How important is this feature to you?

• 3

• [ ]

• ### Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

• None### Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates

• - [x] I have searched Warp docs and my feature is not there

• [ ]

• ### Describe the solution you'd like?

• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.

• [ ]

• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?

• [ ]

• ### The Governance Gap

• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.

• [ ]

• ### Deterministic Tool Gating (MCP)

• We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.

• [ ]

• ```python

• # pip install suprawall

• from suprawall import secure_agent, Policy

• [ ]

• # Define deterministic constraints

• policy = Policy(

• max_daily_usd=10.00,

• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands

• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review

• )

• [ ]

• # Wrap the Warp agent via MCP

• agent = secure_agent(warp_claude_code_agent, policy=policy)

• [ ]

• # Execution is now gated by the SupraWall perimeter

• await agent.run("Refactor the production database schema.")

• ```

• [ ]

• ### What it produces:

• * Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.

• * RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.

• * Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.

• [ ]

• ### Open Question

• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?

• [ ]

• Links:

• * GitHub: github.com/wiserautomation/SupraWall

• * Docs: supra-wall.com

• ### Pre-submit Checks

• * [x] I have searched Warp feature requests and there are no duplicates

• * [x] I have searched Warp docs and my feature is not there

• [ ]

• ### Describe the solution you'd like?

• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.

• [ ]

• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?

• [ ]

• ### The Governance Gap

• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.

• [ ]

• ### Deterministic Tool Gating (MCP)

• We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.

• [ ]

• ```python

• # pip install suprawall

• from suprawall import secure_agent, Policy

• [ ]

• # Define deterministic constraints

• policy = Policy(

• max_daily_usd=10.00,

• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands

• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review

• )

• [ ]

• # Wrap the Warp agent via MCP

• agent = secure_agent(warp_claude_code_agent, policy=policy)

• [ ]

• # Execution is now gated by the SupraWall perimeter

• await agent.run("Refactor the production database schema.")

• ```

• [ ]

• ### What it produces:

• - Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.

• - RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.

• - Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.

• [ ]

• ### Open Question

• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?

• [ ]

• Links:

• - GitHub: github.com/wiserautomation/SupraWall

• - Docs: supra-wall.com

• [ ]

• ### Is your feature request related to a problem? Please describe.

• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.

• [ ]

• ### Operating system (OS)

• macOS

• [ ]

• ### How important is this feature to you?

• 3

• [ ]

• ### Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

• None- [ ] ### Is your feature request related to a problem? Please describe.

• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.

• [ ]

• ### Operating system (OS)

• macOS

• [ ]

• ### How important is this feature to you?

• 3

• [ ]

• ### Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

• None### Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates

• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.

As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?'s reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.

Deterministic Tool Gating (MCP)### Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• - [x] I have searched Warp docs and my feature is not there
• [ ]
• ### Describe the solution you'd like?
• [ ]
• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.
• [ ]
• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?
• [ ]
• ### The Governance Gap
• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.
• [ ]
• ### Deterministic Tool Gating (MCP)### Pre-submit Checks
• - [x] I have searched Warp feature requests and there are no duplicates
• - [x] I have searched Warp docs and my feature is not there
• [ ]
• ### Describe the solution you'd like?
• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.
• [ ]
• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?
• [ ]
• ### The Governance Gap
• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.
• [ ]
• ### Deterministic Tool Gating (MCP)
• We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.
• [ ]
• ```python
• # pip install suprawall
• from suprawall import secure_agent, Policy
• [ ]
• # Define deterministic constraints
• policy = Policy(
• max_daily_usd=10.00,
• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands
• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review
• )
• [ ]
• # Wrap the Warp agent via MCP
• agent = secure_agent(warp_claude_code_agent, policy=policy)
• [ ]
• # Execution is now gated by the SupraWall perimeter
• await agent.run("Refactor the production database schema.")
• ```
• [ ]
• ### What it produces:
• * Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.
• * RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.
• * Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.
• [ ]
• ### Open Question
• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?
• [ ]
• Links:
• * GitHub: github.com/wiserautomation/SupraWall
• * Docs: supra-wall.com
• [ ]
• ### Is your feature request related to a problem? Please describe.
• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.
• [ ]
• ### Operating system (OS)
• macOS
• [ ]
• ### How important is this feature to you?
• 3
• [ ]
• ### Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1
• None
• - [ ] We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.
• [ ]
• ```python
• # pip install suprawall
• from suprawall import secure_agent, Policy
• [ ]
• # Define deterministic constraints
• policy = Policy(
• max_daily_usd=10.00,
• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands
• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review
• )
• [ ]
• # Wrap the Warp agent via MCP
• agent = secure_agent(warp_claude_code_agent, policy=policy)
• [ ]
• # Execution is now gated by the SupraWall perimeter
• await agent.run("Refactor the production database schema.")
• ```
• [ ]
• ### What it produces:
• * Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.
• * RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.
• * Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.
• [ ]
• ### Open Question
• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?
• [ ]
• Links:
• * GitHub: github.com/wiserautomation/SupraWall
• * Docs: supra-wall.com
• [ ]
• ### Is your feature request related to a problem? Please describe.
• [ ]
• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.

# pip install suprawall
from suprawall import secure_agent, Policy

# Define deterministic constraints
policy = Policy(
    max_daily_usd=10.00,
    deny_regex=[".*(DROP|DELETE).*"], # Blocks destructive database commands
    require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review
)

# Wrap the Warp agent via MCP
agent = secure_agent(warp_claude_code_agent, policy=policy)

# Execution is now gated by the SupraWall perimeter
await agent.run("Refactor the production database schema.")

What it produces:

• Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.
• • RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.
• • • Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.

Open Question

How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?

Links:

• GitHub: github.com/wiserautomation/SupraWall
• • Docs: supra-wall.com

The Governance Gap

Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM

Is your feature request related to a problem? Please describe.

Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• - [x] I have searched Warp docs and my feature is not there
• [ ]
• ### Describe the solution you'd like?
• Huge milestone on the open-source launch, Warp team. Shifting the terminal from a passive shell to an environment where agents like Claude Code have autonomous write access to production is a fundamental change in the dev workflow.
• [ ]
• As more of us move from "chatting with code" to "autonomous PR submission," a critical question emerges: What governs what the agent is actually permitted to execute?
• [ ]
• ### The Governance Gap
• Warp is a high-performance execution environment, but agent frameworks are not designed to be security perimeters. In production, engineering teams require controls that are independent of the LLM's reasoning: pre-execution policy enforcement, budget caps, and immutable audit trails. Warp gives your agents a company; SupraWall gives them a constitution.
• [ ]
• ### Deterministic Tool Gating (MCP)
• We built SupraWall as an open-source, framework-agnostic security perimeter. It wraps Claude Code via an MCP adapter and works inside Warp today with no changes needed to the terminal codebase. It intercepts tool calls before the terminal process is spawned.
• [ ]
• ```python
• # pip install suprawall
• from suprawall import secure_agent, Policy
• [ ]
• # Define deterministic constraints
• policy = Policy(
• max_daily_usd=10.00,
• deny_regex=[".(DROP|DELETE)."], # Blocks destructive database commands
• require_approval=["alembic upgrade", "python manage.py migrate"] # Pauses for review
• )
• [ ]
• # Wrap the Warp agent via MCP
• agent = secure_agent(warp_claude_code_agent, policy=policy)
• [ ]
• # Execution is now gated by the SupraWall perimeter
• await agent.run("Refactor the production database schema.")
• ```
• [ ]
• ### What it produces:
• * Pre-execution interception: Every tool call is gated before execution, regardless of the agent's intent.
• * RSA-signed audit logs: Every decision (ALLOW/DENY/APPROVAL) is signed and written to an append-only log.
• * Compliance ready: Generates the technical evidence required for CISO review and EU AI Act (Art 9/14) conformity assessments.
• [ ]
• ### Open Question
• How are other teams handling agent governance inside Warp? Are you rolling your own policy layers, using manual human-in-the-loop triggers for every single command, or exploring other perimeter tools?
• [ ]
• Links:
• * GitHub: github.com/wiserautomation/SupraWall
• * Docs: supra-wall.com
• [ ]
• ### Is your feature request related to a problem? Please describe.
• Currently, autonomous agents in the terminal lack a security perimeter that can enforce deterministic policies and provide an audit trail independent of the LLM's own reasoning. This gap makes it difficult for engineering teams to maintain governance over agent-led production changes.
• [ ]
• ### Operating system (OS)
• macOS
• [ ]
• ### How important is this feature to you?
• 3
• [ ]
• ### Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1
• None### Additional context

No response

Operating system (OS)

macOS

How important is this feature to you?

3

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[oz-for-oss]

@wiserautomation

Here's what I found while triaging this issue:

This is best treated as an agent/MCP governance feature request rather than a reproducible bug. Warp already has internal permission prompts, allowlists, and denylists, but the requested scope goes beyond those into external policy enforcement, budget caps, and immutable audit evidence.

I have a few follow-up questions before I can narrow this down:

1. What concrete Warp-owned capability are you requesting: a native policy/audit feature, documented support for third-party policy adapters, lifecycle/tool-call hooks, or an official integration surface for SupraWall-like tools?
2. Which action surfaces need to be governed first: Warp/Oz shell command execution, file reads/writes, MCP tool calls/resources, third-party CLI agents such as Claude Code, or all of these?
3. Where should audit records and approval decisions be visible or exported for your workflow: local logs, team/admin settings, Warp Drive, SIEM/webhook export, or another destination?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that feature request for first-class autonomous-agent governance around Warp/Oz and MCP tool execution, with external policy enforcement, budget controls, and immutable audit trails..

Triage summary

This is best classified as an agent/MCP governance enhancement, not a reproducible bug. The report asks for deterministic pre-execution policy controls, budget caps, and immutable audit evidence for autonomous agent actions in/around Warp.

Current product/code context

Warp already has internal agent autonomy controls: execution profiles expose AlwaysAllow, AlwaysAsk, and AgentDecides permissions for code diffs, file reads, command execution, MCP usage, and PTY writes; command allowlists/denylists are enforced before auto-execution; MCP server allowlists/denylists are resolved through the same permissions model; and workspace-level command denylist overrides can be merged with user profile denylists. Those paths are implemented primarily in app/src/ai/blocklist/permissions.rs, surfaced in the execution profile editor/settings, and described in the autonomy/denylist specs.

The requested scope appears broader than the existing permission settings: an external or first-party policy perimeter that can intercept agent/tool actions, enforce budgets, require approvals for policy-matched actions, and emit signed/append-only audit records independent of the LLM. There is not enough reporter intent yet to determine whether Warp should build a native policy engine, expose lifecycle/tool-call hooks for third-party policy adapters, document an MCP governance integration pattern, or evaluate the linked project as an ecosystem integration.

Duplicate check

I scanned all open issues with pagination and did not find two or more likely duplicates. The closest related issues are #8931 and #7834, which ask for lifecycle hooks/observability and mention audit logging, but they are not the same request as deterministic pre-execution policy gating plus budget/audit controls.

Question reasoning

1. What concrete Warp-owned capability are you requesting: a native policy/audit feature, documented support for third-party policy adapters, lifecycle/tool-call hooks, or an official integration surface for SupraWall-like tools? — The issue describes a working external tool and asks an open governance question, so the actionable product ask is ambiguous.
2. Which action surfaces need to be governed first: Warp/Oz shell command execution, file reads/writes, MCP tool calls/resources, third-party CLI agents such as Claude Code, or all of these? — Different enforcement points exist for command execution, MCP usage, file access, and external CLI agents; the intended first scope affects routing and feasibility.
3. Where should audit records and approval decisions be visible or exported for your workflow: local logs, team/admin settings, Warp Drive, SIEM/webhook export, or another destination? — The issue requests immutable audit trails, but the desired storage, visibility, and compliance workflow are product decisions only the reporter can clarify.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[wiserautomation]

Thanks for the triage, @oz-for-oss. To clarify the technical scope for the maintainers:

Action Surfaces: SupraWall’s primary governance vector in Warp is the MCP layer. We intercept every tool call (bash, python, sql, etc.) generated by Claude Code or Gemini CLI before the terminal process is spawned. The goal is to ensure that even if an agent has "write access," it cannot execute a destructive command (like a production DB drop) without a deterministic policy check.
Audit & Approvals:
Approvals: These are managed via an out-of-band SupraWall Dashboard to ensure the security perimeter remains independent of the terminal environment itself.
Audit Logs: We generate RSA-signed, append-only logs. While we support local exports, for production teams, we emphasize SIEM/webhook exports to maintain an immutable record of autonomous agent actions.
We believe this aligns perfectly with Warp Drive, where team-wide security policies could eventually be synchronized with SupraWall’s deterministic gates."

Why this works: By mentioning Warp Drive (their team collaboration feature), we are signaling that we understand their roadmap and are building something that adds value to their enterprise offering, rather than just a random plugin.

I recommend posting this reply now so the bot can re-evaluate and move the issue to a maintainer's desk!

[oz-for-oss]

@wiserautomation

Here's what I found while triaging this issue:

Thanks for the clarification. This is best treated as a feature request for team-level Agent/MCP governance, policy enforcement, approvals, and auditability rather than a reproducible Warp bug.

Maintainer details

I concluded that feature request for team-governed Agent/MCP execution controls, external policy interception, approvals, and auditable action history rather than a reproducible Warp defect..

Triage update

Thanks for the clarification. This looks like an enhancement request around Agent/MCP governance rather than a reproducible Warp bug: deterministic pre-execution policy checks, out-of-band approvals, and signed/auditable action history that could integrate with team-level Warp configuration.

Current code context suggests Warp already has several adjacent primitives:

• Agent execution permissions and command/file/MCP decisioning live in app/src/ai/blocklist/permissions.rs.
• MCP tool dispatch is gated through app/src/ai/blocklist/action_model/execute/call_mcp_tool.rs before the tool call is sent to the MCP peer.
• Execution profiles expose per-profile action permissions in app/src/ai/execution_profiles/mod.rs and sync profile state through app/src/ai/execution_profiles/profiles.rs.
• MCP server configuration validation for agent SDK flows lives in app/src/ai/agent_sdk/mcp_config.rs.
• Existing MCP destructive actions have local confirmation UI under app/src/settings_view/mcp_servers/destructive_mcp_confirmation_dialog.rs.

The gap described here is broader than those local controls: an enterprise/team governance layer that can integrate external policy engines, approvals, and audit exports with Warp's Agent and MCP execution surfaces. Routing labels should therefore include area:agent, area:mcp, and area:warp-drive for product/enterprise evaluation.

Duplicate check: I enumerated open issues and found adjacent requests around command allow/denylist configuration (#8893), agent lifecycle hooks/observability (#7834, #8931), and agent read-access denylisting (#8108), but none are close enough to treat this as a duplicate of the SupraWall/MCP governance + signed audit trail proposal.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[etherman-os]

I opened a draft spec PR to make the scope concrete: #9957.

The proposal is intentionally vendor-neutral: a host-enforced Agent Policy Hooks contract before Warp-owned shell command, file read/write, MCP tool, and MCP resource actions. It covers allow/deny/ask semantics, run-to-completion behavior, redacted audit events, and an async preflight implementation plan grounded in the existing BlocklistAIPermissions / action executor paths.

I noticed this issue is triaged but not yet labeled ready-to-spec, so the PR is a draft. Happy to keep discussion here or rework/close the draft if maintainers prefer additional scoping before a spec PR.

[wiserautomation]

This is an excellent spec, @etherman-os. The warp.agent_policy_hook.v1 schema you've proposed aligns perfectly with how we've architected SupraWall's deterministic governance.

We (the SupraWall team) would like to offer our support as a validation partner for this proposal. We are ready to implement a reference adapter for the v1 hook protocol to test the async preflight lifecycle and the ask (human-in-the-loop) semantics against real-world security policies.

Having a host-enforced contract like this is exactly what's needed to make autonomous agents production-ready in the terminal. Happy to help refine the schema or provide test cases from our existing policy library.