I Let AI Touch Production, With a Kill Switch
A production-shaped AI agent where every tool call is permissioned, risky actions wait for approval, and one switch can stop the system.

CONTROL PLANE · AGENTIC AI · R&D V1 · SANDBOX
0103
In plain English
I built the control layer between an AI agent and the systems it wants to use. The agent may propose an action, but permissions, risk rules, and approval requirements are checked before anything changes. Operators can inspect, approve, reject, trace, or stop execution.
Business value
- Introduces agentic automation gradually instead of granting unrestricted access
- Limits the blast radius of incorrect, unexpected, or overconfident actions
- Creates reviewable evidence for support, governance, and incident investigation
- Automates routine work while keeping people in control of exceptions
Guarded Action Control Plane
A prototype control plane that classifies, queues, and checks agent requests before any write reaches a connected system. High-risk actions stay visible, require explicit approval, and can be stopped from one place.

- Role
- Independent R&D / AI Platform Engineering
- Design · Build · Ship
- Timeframe
- 2026
- Domain
- Agentic AI / API Governance / CRM Automation
- Category
- AI Systems
- Built a sandboxed agent control layer around scoped tools and synthetic CRM data.
- Default-deny policies check identity, tool, fields, and risk before execution.
- Sensitive writes pause for approval; audit trails and kill switches keep operators in control.
- Built a sandboxed agent control layer around scoped tools and synthetic CRM data.
- Default-deny policies check identity, tool, fields, and risk before execution.
- Sensitive writes pause for approval; audit trails and kill switches keep operators in control.
The Moment AI Stops Being a Chatbot
Agentic AI becomes a different product the moment it can do more than draft an answer. If it can update a CRM record, call an internal API, or start a business workflow, it now has operational authority.
I started this independent R&D build with one uncomfortable question: what would I need in place before I was willing to let an agent operate near production?
The prototype uses synthetic records and a sandboxed workflow. No client account or customer data is involved. The point is to solve the permission, review, traceability, and shutdown decisions a real rollout would force into the open.
The Risk Wasn’t Intelligence. It Was Authority.
Traditional software follows code paths engineers already defined. An agent can choose its next action at runtime. That flexibility is useful, but it creates a gap: ordinary application permissions are often too broad, while a simple confirmation dialog gives too little context.
I needed the system to answer five questions clearly: who is asking, which tool do they want, what data will change, does a person need to approve it, and can the action still be stopped?
Ownership
Everything I designed, built, and was accountable for.
Product & UX
- Agent control-layer product framing and workflow design
Engineering
- Laravel policy layer and structured action-proposal API
- Tool permissions, audit trail, and kill-switch design
Additional scope
- Angular approval queue and operator controls
- Synthetic CRM sandbox and demo scenarios
Key decisions
The calls I made, what I rejected, and why: these are the tradeoffs that shaped the system.
Put a default-deny policy layer between the model and every operational tool.
Letting the model call application APIs directly when a prompt says the action is allowed.
Prompt instructions influence behavior; they do not enforce authority. A structured proposal and policy decision create a boundary the model cannot talk its way around.
Autonomy isn’t the absence of control. It’s control moved to the right layer.
A Control Plane Between Intent and Action
I designed the prototype around one rule: the model never talks directly to an operational API.
The agent submits a structured action proposal to a Laravel control layer. That layer checks the actor, environment, tool, requested fields, and action risk. Access is default-deny. Low-risk reads may continue; sensitive writes enter an Angular approval queue that shows exactly what the agent wants to do and what payload will be sent.
The design adds schema validation, field allowlists, timeouts, rate limits, and an audit trail connecting the proposal, policy decision, reviewer response, and tool result. Global and scoped kill switches can stop all new execution or disable one agent, tool, or workflow without taking the rest of the application down.
0104
Reviewed outcomes · policy calibration
Frontend
Backend
Database
Infrastructure
Also used
The agent could suggest anything. It could only do what policy allowed.
What the Prototype Can Prove
- Default-deny tool access
- Human approval gates
- Auditable AI actions
The prototype makes agent behavior visible before, during, and after execution. Unauthorized requests are rejected before reaching an adapter. Elevated actions pause for review. The operator can approve or deny the request, inspect the decision path, and stop new work with a scoped kill switch.
These are demo-level, qualitative outcomes—not a client deployment or invented productivity claim. The real result is a defensible control pattern for moving from AI assistance to AI action.
Permissioned, reviewable, auditable, and stoppable AI actions.
This design offers a credible path for introducing agentic automation without handing an AI unrestricted access on day one. It supports gradual rollout, limits the blast radius of mistakes, gives reviewers useful context, and preserves evidence when an action needs investigation. Independent R&D concept; no client ROI or production metric is claimed.
“Rusty understands the difference between adding features and making software actually usable. He looks at how people work, finds the friction, and improves the system in a way that makes daily operations feel smoother.”
Operations Stakeholder
Internal Platform Team — name under NDA
The Approval Screen Is Part of the Product
The most important interface in an agentic system may not be the chat window. It may be the screen where a person has just enough context to make a good decision.
Guardrails cannot live in prompt text alone. Prompts shape behavior; permissions enforce boundaries. Once I treated authority as its own product surface, the architecture became much clearer.
The goal is not to make an agent harmless by making it useless. It is to make its freedom explicit, reviewable, and reversible.
The agent could suggest anything. It could only do what policy allowed.
Ship agency without surrendering control.
10+
3
5+
10+
Building AI agents that can act without overreaching?
Let’s map the permission model, approval gates, observability, and shutdown path before your agent receives production access.
Discuss Your System