Safe Action MCP

A self-hosted Alexa+ MCP execution firewall that binds high-impact tool calls to fresh evidence, exact owner consent, deterministic replay, and inspectable outcomes.

Comment

Inspiration

AI agents are becoming capable of calling increasingly powerful tools: booking services, changing account settings, making purchases, and triggering external workflows.

The problem is that a user's approval can drift away from what an agent actually executes. A price can change, an argument can mutate, a retry can duplicate an action, or a tool result can be forged.

Safe Action MCP explores a simple question:

How can an AI assistant use consequential MCP tools without losing human control?

What it does

Safe Action MCP is a self-hosted MCP execution control layer for high-impact agent actions.

The demo uses a simulated paid home-service appointment hold. Before the action can execute, Safe Action MCP:

  • validates the tool's risk manifest and supporting evidence
  • checks freshness, integrity, and policy state
  • shows the exact material arguments to the owner
  • binds consent to the exact provider, service, date, time, and quoted price
  • rejects material argument changes after approval
  • executes only a reversible local simulation
  • survives an injected crash without repeating the side effect
  • verifies the result against persisted activity state
  • reconciles intended vs. observed state
  • produces an inspectable decision receipt and execution trace

No real payment or booking is performed.

How we built it

Safe Action MCP uses the Model Context Protocol specification 2025-11-25 over Streamable HTTP.

The stack is:

  • Python 3.11+
  • FastAPI
  • Pydantic
  • SQLite
  • pytest
  • vanilla HTML, CSS, and JavaScript

The web client performs real MCP initialization, tools/list, and tools/call requests against the self-hosted server.

The execution path is:

MCP request → risk manifest → evidence validation → trust gate → exact owner consent → bound action → reversible simulator → durable workflow → result verification → reconciliation → decision receipt

The workflow is event-driven and replayable. If a crash occurs after the simulator has completed the action, the workflow is reconstructed from persisted events and the action is not executed twice.

Challenges we ran into

The hardest part was making the safety controls actually enforce execution rather than simply describe it.

During adversarial testing we found several cases where a security concept existed in the architecture but did not yet control the real execution path.

We corrected those by making evidence and trust checks fail closed, validating results against persisted holds and activities, enforcing initialized MCP sessions, and making decision receipt identity deterministic over material inputs.

We also tested argument mutation, stale manifests, rollback attempts, forged results, idempotency conflicts, crash recovery, invalid sessions, and malformed MCP requests.

Accomplishments that we're proud of

  • A real self-hosted MCP server using Streamable HTTP
  • Exact, scope-bound human consent
  • Field-level mutation detection instead of opaque hash errors
  • Fail-closed evidence and trust enforcement
  • Crash-safe replay with exactly one simulated side effect
  • Persisted activity and result verification
  • Deterministic decision receipts
  • Reversible local execution with no real-world side effects
  • 71 passing tests with zero failures or skips
  • A clean install reproduces the full test suite

What we learned

The biggest lesson was that agent safety is not one check.

Reliable tool execution requires several boundaries to work together: evidence quality, trust freshness, consent scope, argument binding, idempotency, durable recovery, result verification, and observability.

We also learned that these controls only matter when they influence the real execution path. Documentation and architecture diagrams are not enough — adversarial tests need to prove that unsafe variants actually fail.

What's next for Safe Action MCP

The current version intentionally uses a reversible local simulator.

Next steps include:

  • richer MCP tool-risk manifests
  • stronger recovery for actions interrupted before completion
  • more complete end-to-end trace projection
  • multi-party and role-based consent
  • additional reversible MCP tool scenarios
  • adapters for real services only where explicit authorization and safe rollback are possible

The long-term goal is to make consequential AI tool execution inspectable, bounded, and recoverable by default.

Built With

Share this project:

Updates

Submission history