Forward Deployed Engineer, how I deliver it, requirement 10 of 12
Approvals and exception handling
In chat, I hold each Gatekeeper tool marked destructive until the signed-in user approves it, with expiry and a record. This path is in early access.
The requirementBuild workflows where an agent proposes an action, a signed-in person approves or rejects it, and unanswered requests are handled rather than dropped.
How I deliver it at a customer
- Mark what changes systemsI register each Gatekeeper tool with the capability it requires, or with none for an open tool. I mark the tools that change a live system as destructive. That server-side flag, not the model, decides which calls need a person. The built-in chat file tools sit outside this flag, so file delete still depends on the model asking first.
- Gate the tool callsBefore a Gatekeeper tool runs, I check that the caller holds the capability it requires, and I log any refusal. A separate tool bridge checks permissions per tool, blocks reserved schemas, and refuses database writes when writes are turned off.
- Classify shell commandsI keep a pattern list that labels each shell command allow, confirm or block. DROP DATABASE and git push --force origin main are blocked, while kubectl delete and helm upgrade get confirm. The one command channel that uses this list today is off by default, and it refuses confirm commands rather than holding them.
- Hold for a personWhen an agent in chat calls a Gatekeeper tool marked destructive, the call stops and becomes a pending confirmation. The confirmation is tied to that tool, its code and its exact arguments. The chat stream sends it with the arguments and the expiry window, but no chat screen displays it yet. If the confirmation cannot be saved, the call fails instead of running.
- Approve or denyThe signed-in user who made the request approves or denies it in the Gatekeeper pending queue, on its admin page or API. API keys and service accounts cannot approve, and the record keeps who resolved it and when. Before the tool runs, I re-check its code, arguments, expiry and the user's capability. A duplicate approval cannot run it twice. This flow does not yet send the request to a different approver.
- Handle the exceptionsA confirmation expires after five minutes by default, and the window is configurable. A sweep every minute marks expired requests and writes each one to the audit log, and an expired request never runs. Denials are logged as well. Policy exceptions go through the Policy Hub, which scores impact times likelihood and rejects the highest scores automatically. High scores need at least two admin approval steps, but today one admin can take both.
Tools I use
| Tool | What it does here | Status |
|---|---|---|
| Platform tool bridgeAvailable | Exposes platform services to agents with a permission check per tool, blocks reserved schemas, and refuses database writes when writes are off. | Available |
| Command classifierEarly access | Labels each shell command allow, confirm or block. The one channel that uses it is off by default and refuses confirm commands. | Early access |
| Gatekeeper confirmations (GET /gatekeeper/api/pending)Early access | Holds Gatekeeper tool calls marked destructive for the requesting user to approve or deny, records who resolved each one, and expires them after five minutes by default. | Early access |
| Policy Hub exceptionsEarly access | Scores each exception as impact times likelihood, rejects the highest scores automatically, and requires one or more admin approval steps. | Early access |
| Public demo on Cloudflare Workers AIDemo only | Runs the approve-or-reject demo on this page. It is connected to no system, so approving records the decision and executes nothing. | Demo only |
Available means shipped and in use. Early access means built but not generally available. Roadmap means designed, not built. Demo only means it powers the public demo, not customer deployments.
Ask for a change to a system. The agent proposes one action, and a policy check either blocks it or holds it for you to approve or reject, with every step in an audit trail. The demo is connected to no system, so nothing is ever executed.
Open the live demoThe other answers
LLM applications in productionOn Luca, model calls normally go through a gateway that holds provider keys, records each chat call and sets a model per task.Prompt engineeringI write the output shape first, measure the prompt against each model's context window, and check replies against that shape.Retrieval-augmented generationChat answers over a customer's own documents, returned with the matched document names, after a check that the caller may use that persona.AI agents and orchestrationI build agents that call your systems through registered tools, still in early access, and workflows that start on business events.Request classification and routingI build automation that classifies each inbound request, plans bounded tasks, and holds high-risk tasks for approval; the dispatcher is in early access.AI workflow orchestrationI map the steps, API contracts, and data flows between a customer's systems and the models before I build the workflow.API and integration designI publish the API contract first, gate it with keys and scopes, then build integrations against it.Hybrid enterprise integrationI connect AI services to your identity, applications and data, and run the platform on Kubernetes on Azure Local.Prototype to productionI take a prototype through generated tests and a two-approval merge gate to a production deploy that rolls back if the new pod keeps crashing or cannot start.Evals and output validationI built a versioned rubric judge for a tutoring app, and I trace failed or slow model calls to their provider.Client-facing deliveryI turn engineering work into updates that client architects, security leads and business owners can each act on.
Built by Gus Assuncao of Gus IT LLC for a Forward Deployed Engineer application. Luca is the AI platform Gus IT builds and operates. Contact gus@gusit.de. Claude is a product of Anthropic PBC. Cloudflare and Workers AI are trademarks of Cloudflare, Inc. Llama is a trademark of Meta Platforms, Inc. Other names are trademarks of their respective owners. Gus IT LLC is an independent engineering firm and is not affiliated with or endorsed by these companies.