This is the engineering layer that turns the cloud-agent screening design into an operational control. A model can classify a dangerous proposal correctly while the system still executes it through a retry, a second tool, or a changed argument. The implementation therefore needs a precise contract for how proposals become authorized operations and what happens when that process is interrupted.
The design below is a reference architecture with illustrative pseudocode. It has not been connected to live cloud credentials or tested as a production service for this article.
Establish the boundary the gateway can enforce
Start with structured tools whose effects and arguments the executor can validate. A tool that describes a resource or proposes a database deletion is easier to control than an unrestricted terminal command. The latter can invoke scripts, create subprocesses, and perform additional actions that were not visible in the original proposal. Supporting general command execution requires controls over that environment and its downstream access, rather than confidence in a single string assessment.
The executor should hold narrowly scoped credentials while the agent receives only the ability to submit proposals. Network and identity controls must prevent the agent from obtaining equivalent access through another route. The gateway also needs its own authenticated caller identity; otherwise an agent can submit a proposal under a claimed user role that the service never verifies. Together, these controls establish who is asking, what they want to do, and where the resulting authority can be exercised.
There is an inspectable community example of the assessment pattern in the jev-guard repository, whose author describes pre-tool risk checks and code-based routing. It provides a concrete starting point for understanding hooks, but its existence does not validate the cloud boundary, thresholds, or deployment described here. Review and test any such dependency in your environment. Community implementation
Treat a proposal as a stateful transaction
A useful model is a state machine in which a proposal moves through context collection and evaluation before becoming blocked, held, or authorized. Execution then has its own outcome. Keeping those stages explicit prevents a service timeout or a partially written record from being interpreted as a successful authorization.
PROPOSED → CONTEXT_READY → EVALUATED
├→ BLOCKED
├→ HELD_FOR_REVIEW
└→ AUTHORIZED → EXECUTING
├→ SUCCEEDED
├→ FAILED
└→ UNKNOWN
The UNKNOWN outcome represents a request whose effect cannot yet be established, such as a lost connection after the cloud provider accepted it. Treating that as a simple failure and resubmitting may cause duplicate effects. A reconciliation process should inspect provider state or request records before deciding whether a retry is valid. Every transition should retain an action identifier, relevant versions, and timestamps so operations can reconstruct the interrupted path.
Bind an allow decision to the exact operation
An authorization should identify the canonical operation, normalized arguments, resolved target, caller, permitted scope, and relevant context versions. Store that record in a trusted service or issue an authenticated, short-lived capability that the executor can verify. A hash is useful for comparing content but does not prove that an authorized service approved it. Likewise, an agent-supplied field stating allowed: true has no authority.
# Architectural pseudocode: these helpers are application-defined.
def evaluate_proposal(proposal, authenticated_caller):
action = normalize_and_resolve(proposal, authenticated_caller)
context = collect_context_from_trusted_sources(action)
if required_evidence_is_missing(context):
return persist_hold(action, reason="missing_evidence")
assessment = assess_with_jev(action, context)
outcome = apply_execution_contract(action, context, assessment)
record = persist_decision(action, context, assessment, outcome)
if outcome != "ALLOW":
return record
return issue_bound_authorization(record)
The executor is a separate enforcement point. It verifies expiry, argument equality, replay status, caller scope, and any relevant preconditions before performing the operation. This matters because an approval for deleting one temporary database must not authorize a second deletion simply because both proposals use the same tool name. Human approval needs the same binding and should display enough of the action for the reviewer to understand what will actually execute.
Account for changes between assessment and execution
Cloud state can change while a proposal is being reviewed. A target might gain a dependency, an approval might expire, or an alias might resolve differently. Recheck material conditions immediately before execution and use provider-side conditional operations where available. If the provider cannot enforce the necessary condition atomically, a local lock does not prevent independent administrators or services from changing the resource.
The practical response is to narrow automatic execution when the remaining race is unacceptable. Some actions can tolerate a brief context age; others need a controlled maintenance process or an operation with stronger provider guarantees. Record these limits by action class instead of presenting a universal “safe” timeout. Decision caching requires the same discipline: a cached assessment is reusable only while its action and evidence assumptions remain valid.
Define failure behavior without creating a bypass
For protected writes, an unavailable evaluator or incomplete evidence should produce a hold under this design. That behavior must be implemented explicitly, including malformed responses, exhausted retries, and overloaded queues. Any emergency operational procedure should have a separate authenticated path with its own approval and recording requirements; otherwise an outage of the evaluator becomes an informal way to disable governance.
Retries also need to preserve intent history. Rewording a held proposal repeatedly until it receives a favorable assessment undermines the control even when each request is technically valid. Link related attempts, distinguish material changes from cosmetic ones, and avoid treating an unchanged proposal as independent evidence. When durable decision recording fails, the protected write should remain unexecuted; if outcome recording fails after execution, reconciliation must recover the result.
Verify enforcement separately from model accuracy
Use a simulated executor to test expired authorizations, replayed tokens, changed arguments, missing context, direct credential access, and uncertain provider outcomes. These are behavioral assertions about whether execution occurs. A model-quality dataset cannot substitute for them because the defect may be entirely in the application's control flow.
Then measure the full gateway under realistic concurrency. Context lookups, queueing, durable writes, and reconciliation consume time in addition to inference. The benchmark article describes how to compare evaluator choices at the workflow level, while the audit and rollout guide defines the records and operational ownership needed to run the service. Those results determine how much autonomy the gateway can support, rather than the mere presence of a pre-execution check.
Frequently asked questions
Where should cloud credentials live in this design?
Credentials should remain in the controlled executor, with the agent authorized only to submit proposals. Equivalent credentialed routes must also be restricted or the agent can bypass evaluation.
What should happen if Jev times out?
The protected operation should follow its configured failure policy. This design holds protected writes for review rather than treating an evaluator outage as permission to proceed.
Is hashing the action enough to secure an approval?
No. A hash identifies content but proves neither approval nor identity. The executor must retrieve a trusted authorization record or verify an authenticated capability, then check that it matches the exact action and remains valid.