Arqon SafeAction

Permission-first AI actions with human approval, safe execution, and auditable results.

Comment

Arqon SafeAction — AI Actions, Human Approval

Inspiration

AI assistants are becoming increasingly capable of taking actions, not just answering questions. But when an assistant can modify information, create records, or trigger workflows, a critical question emerges:

How do we give AI agents useful capabilities without giving up human control?

An AI assistant should be able to suggest an action, but sensitive or consequential changes should not happen without appropriate authorization.

This inspired Arqon SafeAction, a permission-first action workflow designed around a simple principle:

AI proposes. Humans decide. The system records the outcome.

For the Amazon Build, Ship, Shape hackathon, we explored this concept through a simulated Alexa+-style assistant experience.

What it does

Arqon SafeAction demonstrates a human-in-the-loop workflow in which an AI assistant can propose an action, but cannot automatically execute that protected action.

The prototype supports:

  • Action proposals: An MCP-compatible tool creates a structured proposal for a fictional checklist operation.
  • Human approval: An authenticated operator reviews the proposed action and explicitly approves or rejects it.
  • Permission-checked execution: An approved action can be saved through the trusted backend workflow.
  • Rejection handling: Rejected proposals do not produce the protected saved result.
  • Persistent records: SQLite stores workflow state so decisions and results can be retrieved.
  • Operator interface: A web dashboard provides proposal review, decision controls, and session management.

The demonstration follows two scenarios:

Scenario A — Approved action

  1. A simulated assistant workflow requests a checklist operation.
  2. An MCP tool creates an action proposal.
  3. The proposal appears for operator review.
  4. The operator approves it.
  5. The backend saves the approved checklist exactly once.
  6. The saved result is verified.

Scenario B — Rejected action

  1. A second proposal is created.
  2. The operator reviews and rejects it.
  3. The rejected checklist is not saved.
  4. The decision and resulting state are verified.

Together, these scenarios demonstrate how AI-driven workflows can remain subject to explicit human control.

How we built it

Arqon SafeAction combines several components:

Python and FastAPI: Backend endpoints for action proposals, operator decisions, workflow state, and persistence.

Model Context Protocol (MCP): A Python MCP server exposes tools for proposing actions and handling decisions through the trusted workflow.

Next.js, React, and TypeScript: A browser-based operator dashboard for reviewing proposals and approving or rejecting actions.

SQLite: Persistent storage for proposals, decisions, and protected checklist results.

Authentication and session controls: Local operator authentication and session handling protect decision-making operations.

The implementation separates the proposal stage from the execution stage. Creating a proposal is not equivalent to receiving permission to perform the action.

The workflow was tested end to end across the MCP server, backend, dashboard, and database.

Challenges we faced

1. Separating AI intent from authorized execution

The central challenge was ensuring that a proposed action could not be mistaken for an approved action. We addressed this through explicit proposal states and a trusted decision workflow.

2. Connecting independent components

The MCP server, FastAPI backend, Next.js dashboard, and SQLite database needed to operate consistently across separate processes.

3. Maintaining persistent workflow evidence

We needed to verify that an approved action was saved exactly once while a rejected action produced no protected result.

4. Preparing a reproducible demonstration

Recording the final demo presented additional technical challenges, including macOS screen-capture restrictions, browser recording failures, and video-encoder errors. We ultimately produced a narrated video assembled from genuine application screenshots, with verification of the underlying workflow.

What we learned

Building SafeAction reinforced several important engineering lessons:

  • Human approval must be enforced by the backend, not merely displayed in the user interface.
  • AI-generated proposals should be distinct from permission to execute.
  • Persistent records are essential for understanding what happened after a decision.
  • A small, clearly defined workflow can demonstrate meaningful AI safety principles.
  • Reproducible testing and transparent limitations matter as much as an impressive interface.

What's next

Arqon SafeAction is currently a local, single-operator prototype.

Potential future improvements include:

  • More granular, role-based permissions.
  • Multiple operators and approval policies.
  • Stronger audit reporting and tamper-evident records.
  • Additional MCP-compatible action types.
  • Integration with real assistant platforms where supported.
  • Deployment architecture and security hardening for production environments.

Our long-term goal is to make human-controlled action execution a reusable building block for AI agents.

Demo and source code

Video demonstration: https://youtu.be/X3HWS7lKuJQ

Open-source repository: https://github.com/mounesh00/arqon-safeaction

License: MIT

Important disclosure

This project demonstrates a simulated Alexa+-style experience. It is not a live Alexa+ integration.

The video is assembled from screenshots of genuine application states, accompanied by narration and captions. The underlying approval, rejection, persistence, and retrieval operations were executed and verified against the prototype's database.

Arqon SafeAction is a demonstration prototype, not a production-ready security or authorization service.

Built With

Share this project:

Updates

Submission history