A Jev tool verdict must bind to the exact action it permits

Agentic AI SeedlingPlanted Sep 2026

I would not let a Jev verdict travel as a reusable “safe” flag. It must remain bound to the exact action, arguments, principal, tenant, and policy version evaluated, with expiry and revocation checked before any side effect. A model verdict informs control; it cannot create authority. The failure I want to prevent is not simply a bad classification. It is a reasonable classification being borrowed to execute a different action.

LangChain’s TypeSafe integration documentation gives this distinction practical importance. Its experimental AutoModeMiddleware judges whether a tool call is risky or insufficiently authorized, intercepts calls through wrap_tool_call, and returns an error ToolMessage instead of executing calls judged risky. Only listed tools receive that classification. LangChain explicitly says the middleware refuses calls; it does not request approval. I read this as a semantic checkpoint, not an authorization lifecycle. Expiry, revocation, and binding across a suspended workflow remain application responsibilities.

Consider an illustrative refund workflow. Jev evaluates returning an agreed amount to the original payment method for one customer. The agent then repairs an argument, switches accounts, or resumes under another tenant. Even if the revised call looks similar, the earlier verdict says nothing about it. A tool name is not enough identity. Neither is a conversation identifier. I want the executor to compare the concrete operation it will dispatch against the operation that was evaluated, rather than trust that the planner preserved its meaning.

My decision record would therefore bind the resolved tool and operation, destination and resource identifiers, every effect-bearing argument, authenticated principal, delegated authority, tenant, and authorization-policy version. I would also retain the model and question versions as evidence about the judgment, not as sources of permission. Defaults must be resolved before evaluation; mutable references need pinned versions or execution-time preconditions. A digest can identify this record, but hashing does not authenticate its issuer. The binding needs protected server-side storage or an authenticated token verified by the executor.

The policy decision must remain separate from the model answer. Cedar’s authorization documentation frames the question around principal, action, resource, and context. That is the shape of authority I want, supplied from authenticated application state rather than a document claiming that its author is an administrator. TypeSafe’s own Jev 1.13 limitations say adversarial content can move the answer and that state is not treated as hostile by default. A favorable judgment must never add a permission the principal lacks.

Freshness is another binding, not a logging field. Before dispatch, I want code to reject an expired decision, check whether the approval or delegated authority was revoked, and verify that the relevant policy version remains current. A changed policy requires a new authorization decision; changed evidence may require a new model judgment too. A deadline cannot substitute for revocation: an unexpired record may already be invalid. If consequential execution depends on a check the runtime cannot complete, I would hold or deny the action rather than inherit yesterday’s answer.

Checking immediately before a write still leaves a race unless the execution boundary enforces the checked conditions. Where available, I would use transactional checks, resource-version preconditions, or a service-side authorization gate. For remote effects, the design must state which boundary orders revocation against execution; a client timestamp cannot make that atomic. Retries need the same discipline. An idempotency key prevents duplicate effects, but it does not renew authority. Human approval must bind to the same proposal, not a summary that survives changed arguments.

My precise concession is that a synchronous, low-risk operation inside one trusted process may not need a signed decision token. An immutable proposal passed directly to an enforcing executor can provide the binding. That concession removes a transport mechanism, not the obligation to execute only the evaluated action under current authority.

I already argue that guardrails belong before effects. The narrower requirement here is continuity: prove that the permitted action is still the action being executed, for the same principal and tenant, under valid policy. Jev can contribute judgment to that proof. It cannot supply the authority the proof depends on.