DWARPAL — The Consent Layer for AI Actions

Before an AI assistant acts, DWARPAL checks authorization, binds approval to the exact plan, and records an inspectable audit receipt.

Comment

DWARPAL — Before AI Acts, Prove the Handoff.

Tagline: Intent is not authority.

Inspiration

AI assistants are evolving from systems that answer questions into agents that plan and coordinate actions across digital and physical environments. However, understanding a user's intent does not automatically grant an assistant permission to execute a consequential action.

Consider a home-service scenario: a resident requests a plumbing inspection and asks that entry be granted only after approval. The assistant can prepare a maintenance plan, but how can the system demonstrate exactly what was requested, whether the required approval was provided, whether the plan changed afterward, and why the proposed action was allowed or denied?

This is the problem DWARPAL explores.

We built DWARPAL around one principle: intent is not authority. Before an AI-assisted workflow proceeds toward a consequential action, its authorization boundary should be explicit, inspectable, and bound to the exact plan being approved.

What It Does

DWARPAL is a policy-first action-governance prototype presented through a simulated Alexa+-style web experience. It demonstrates how an AI-assisted workflow can separate preparing an action from authorizing it.

Instead of hiding decisions behind a conversational response, DWARPAL exposes the workflow stages, policy results, reason codes, canonical plan digest, approval state, and audit events through an interactive interface.

The prototype uses fictional home-service cases and includes four interactive scenarios:

  • Safe Approved Path: Demonstrates the workflow when the required simulated approval conditions are satisfied.
  • Missing Approval: Demonstrates fail-closed denial when required approval evidence is absent.
  • Tampered Plan Hash: Demonstrates rejection when the submitted plan no longer matches the persisted plan.
  • Replay Prevention: Demonstrates rejection of a repeated approval attempt after finalization.

DWARPAL does not unlock real doors, authenticate real residents, contact contractors, or dispatch municipal services.

How We Built It

DWARPAL uses Python, FastAPI, SQLite, and a browser-based HTML, CSS, and JavaScript interface.

1. Seven-Stage Workflow

The application models an explicit lifecycle:

  1. Case context loaded.
  2. Maintenance proposal created.
  3. Plan preview prepared.
  4. Homeowner approval requested.
  5. Policy evaluated.
  6. Access-scope previewed or request denied.
  7. Audit receipt prepared.

The interface visualizes these stages so reviewers can inspect the workflow rather than seeing only its final result.

2. Canonical Plan Integrity

DWARPAL creates a deterministic canonical representation of the proposed plan and calculates its SHA-256 digest. Approval is bound to that specific representation. Before accepting approval, the backend checks the persisted plan and rejects changes that invalidate the original approval.

This helps demonstrate why approval must apply to the exact requested action rather than a loosely worded intention.

3. Fail-Closed Policy Enforcement

The local policy engine evaluates authorization conditions and denies unknown actions, unauthorized roles, and requests that do not meet the required approval conditions. Structured reason codes explain the outcome.

4. Single-Use Approval and Replay Prevention

The workflow uses a conditional finalization transition intended to prevent an already finalized approval from being reused. Repeated approval attempts are rejected instead of being treated as new authorization.

5. Explainable Risk Assessment

A deterministic, rules-based assessment considers factors such as simulated identity evidence, homeowner approval, and physical-entry sensitivity. It displays a risk level, reason codes, and a recommended next step.

This is an explainable rules-based assessment, not a trained machine-learning risk model.

6. Audit Receipts and Decision Provenance

DWARPAL records structured workflow events in a local SQLite store. Its provenance interface connects the fictional case, proposed action, plan digest, policy decision, reason code, and audit information.

The result is a more inspectable decision process: reviewers can examine why a workflow was allowed or denied and what evidence was recorded.

7. Interactive Scenario Testing

Four backend-driven presets let reviewers test successful and denied paths directly through the interface. The scenarios make approval requirements, plan-integrity checks, and replay prevention observable instead of relying only on architecture diagrams or written claims.

Design and User Experience

DWARPAL combines a bold editorial interface with a neo-brutalist visual language: warm cream and peach surfaces, coral and violet accents, high-contrast typography, lime highlights, sharp borders, and offset shadows.

The experience is organized around four questions:

  • What action is being proposed?
  • What exactly is being approved?
  • Why did the policy allow or deny it?
  • What evidence was recorded?

The seven-stage timeline, interactive presets, decision-provenance panel, architecture trace, and audit receipts make the authorization process easier to explore and understand.

The design emphasizes both successful and denied outcomes because a governance system must make its boundaries visible, not merely celebrate successful execution.

Technical Verification

The final execution report records:

  • 24 passing automated tests.
  • Successful Python compilation.
  • Successful JavaScript syntax validation.
  • Successful local HTTP smoke tests.
  • Execution of all four scenario presets.
  • Reported browser-based interaction testing.

These are results reported by the development environment and do not establish that every optional external integration has been verified.

The project includes an MCP Streamable HTTP integration path, but successful external MCP client tool discovery and invocation were not verified in the reported run. The primary experience for this submission is therefore the simulated Alexa+-style web application, an approach explicitly permitted by the hackathon requirements.

Amazon Bedrock, Strands, and AWS Verified Permissions are not claimed as configured live services in the default submission.

Challenges and Learning

One of the main engineering challenges was ensuring that approval applied to the exact persisted plan rather than a general description of user intent. This led to deterministic plan serialization, SHA-256 digest verification, explicit approval states, fail-closed policy decisions, and replay-rejection tests.

Another important lesson was distinguishing an implemented integration point from a verified end-to-end integration. A mounted endpoint or adapter alone does not prove that an external client or cloud service works correctly. DWARPAL documents these boundaries instead of presenting unverified capabilities as completed integrations.

Potential Impact

The approach explored by DWARPAL could inform future agentic systems that coordinate sensitive or consequential workflows, including home-service access, facilities operations, equipment maintenance, and other human-approved actions.

A production implementation would require real identity and consent verification, appropriately scoped authorization, secure and durable audit storage, operational monitoring, and validated integration with systems that perform the actual actions.

DWARPAL is an early prototype exploring this governance layer, not a claim that these production requirements have already been fulfilled.

What's Next?

Future work includes validating the MCP server with an external compatible client, testing a real authorization-service integration, strengthening production identity and audit controls, and evaluating the workflow against real operational systems in a controlled environment.

DWARPAL makes one question unavoidable before an AI-assisted action proceeds: Who authorized this exact plan, and what evidence supports that decision?

Built for the Build, Ship, Shape: Amazon Developer Hackathon. DWARPAL is an independent prototype and is not an official Amazon product.

Built With

Share this project:

Updates

Submission history