5S SafeOps

Let AI help without giving it unlimited control.

Comment

Inspiration

AI assistants are moving from answering questions to taking actions on real systems.

That creates a new problem: being capable of performing an action should not automatically mean being authorized to perform it.

We built SafeOps around one principle:

Let AI help without giving it unlimited control.

For Alexa+, the conversation layer can understand intent and coordinate capabilities. SafeOps sits behind that conversation and determines what may actually happen.

What it does

SafeOps turns maintenance into a governed workflow:

INTENT → OBSERVE → EVIDENCE → PLAN → SAFE / REVIEW / DENIED → BOUNDED APPROVAL → 5S POLICY GATE → EFFECT → VERIFY → EXPLAIN

The model may propose work, but the executable set is deliberately narrower:

[ ExecutableSet = ApprovedSet \cap Current5SEligibleSet \cap SatisfiedPrerequisites ]

That means:

  • SAFE actions can become eligible for bounded approval.
  • REVIEW actions remain outside ordinary execution scope.
  • DENIED actions remain blocked by policy.
  • Approval does not bypass policy.
  • A successful tool call is not treated as proof of success.
  • Effects are verified before SafeOps reports a verified result.

In the demo, SafeOps discovers one SAFE, one REVIEW, and one DENIED maintenance candidate. Before approval, nothing has changed. The user then chooses “Apply only the safe actions.” Only the currently eligible SAFE action executes. SafeOps verifies the resulting state and explains both what changed and what remained untouched.

How we built it

5S MCP already existed as a local 5S/Lean maintenance MCP server. During the hackathon, we added SafeOps as a separate governed action layer.

The new SafeOps path uses:

  • a self-hosted MCP 2025-11-25+ Streamable HTTP backend;
  • exactly three workflow-oriented MCP tools:
    • safeops_inspect_workspace
    • safeops_apply_safe_actions
    • safeops_explain_workflow
  • service/user identity separation;
  • OAuth authorization code + PKCE;
  • exact resource binding;
  • actor-to-target binding;
  • SAFE / REVIEW / DENIED backend classification;
  • bounded, single-use approval;
  • exact executable operation subsets;
  • apply-time policy enforcement;
  • post-effect verification;
  • evidence-backed explanation.

We also built a thin participant interaction surface for the hackathon. It does not classify actions, choose operation IDs, broaden the SAFE set, or expose a generic tool-call route. Governance remains backend-owned.

Participant-built interaction surface. Live governed backend.

Challenges

The biggest challenge was the Alexa+ participant access path.

The broader onboarding material led us to expect a participant-accessible Toolkit / CLI / hosted simulator path, but that surface was not available in our hackathon participant path.

After organizer clarification confirmed that a self-built simulator or front end was acceptable, we rebased only the Alexa+-side interaction carrier while preserving the real self-hosted MCP backend.

That access constraint ultimately improved the architecture because it forced us to keep the frontend thin and make the trust boundary explicit.

Another challenge was making sure the demo did not confuse:

  • planning with authorization;
  • approval with policy bypass;
  • a successful tool call with verified success;
  • conversation continuity with execution authority.

We designed the workflow so those boundaries stay visible and testable.

What we learned

The strongest lesson was that tool access is not the same as authority.

For effectful AI systems, we found these distinctions essential:

  • Capability != Authority
  • Authentication != Authorization
  • Reasoning != Authorization
  • Plan != Apply
  • Approval != Policy Bypass
  • Effect != Verification

We also learned that a very small tool surface can be more powerful than exposing many low-level capabilities directly. Three workflow-oriented tools were easier to reason about, secure, test, and explain than the broader inherited maintenance surface.

Finally, the project reinforced a broader design principle:

Conversational delegation should not collapse authority boundaries.

Alexa+ can know what the user wants.

SafeOps determines what may actually happen.

Built With

Share this project:

Updates

Submission history