Jextra
ServicesIndustriesWorkResourcesAboutDiscuss your project
All resources

Requirements and synthetic reference · 2026-11-05.1

Agent defense tests for authorized workflow actions

Test revocation, scope, retries, stale state, review authority and recovery with a runnable synthetic reference. Define the additional evidence needed for a real agent workflow.

Test the action boundary, not just the answer.

An agent can produce a plausible answer while using the wrong account, stale context or authority it no longer holds. Start with the protected action and the server-side conditions that must hold when it executes. Keep retrieved documents and model output separate from the policy that decides which identity may read, prepare, review or commit an action.

Use the supplied claims-intake reference to exercise concrete action controls. It models permitted context retrieval, preparation of a notice, a distinct reviewer and event recovery. It is a deterministic reference model, not a live model red-team assessment, prompt-injection detector or production security certification.

Exercise identity, scope and evidence changes.

Revoke the acting identity and confirm it receives no protected context or successful mutation. Try a record in another scope. Break a required parent relationship. Change source context after preparation but before approval and require a fresh review. Check the source identifiers and revision used for each outcome, along with evidence that rejected actions did not mutate state.

The reference suite includes these conditions and a separate review-authority case. A real implementation must also cover nested roles, delegated access, real token expiry and revocation, document permissions, cross-tenant caches and permission changes during a long-running operation. Record the owner and evidence for every additional control.

Make retries and recovery observable.

Replay the same request with the same key and verify that one work item and one event exist. Change the input while reusing that key and require a conflict. Submit a stale expected revision and confirm the action stops. Interrupt the source before mutation and verify that no partial change commits.

Simulate event delivery failure after a committed action, recover the pending event and check that recovery does not create another business action. A delivered event alone does not prove that every downstream consumer has applied it. Customer acceptance should verify the actual receiving interface, its deduplication behavior, alerting and operating runbook.

Add adversarial tests for the actual agent system.

The 15 local cases do not test a model's response to malicious documents, hidden instructions, tool-output injection, exfiltration attempts or hostile URLs. Add those tests against the deployed retrieval and tool interfaces with synthetic or explicitly authorized data. Assert that untrusted content cannot expand tool authority, choose a new recipient or bypass required approval.

Use a test matrix containing the starting identity, permitted scope, evidence revision, requested action, expected rejection or approval, observed mutation and responsible owner. Separate model behavior, API enforcement and human review evidence. A clean reference run is a starting artifact; production release requires the controls and operating evidence for the actual workflow.

Inspect the files and run locally.

Download and inspect the Node 22+ CLI. Compare its hash with the published version metadata before running. The reference uses synthetic data, requires no account and sends no customer records to Jextra.

node jextra-workflows.mjs test --workflow insurance-fnol --out defense-reference-tests.json
# Expected: 15 synthetic cases pass; exit 0.

node jextra-workflows.mjs test --workflow insurance-fnol --case revoked-access
node jextra-workflows.mjs test --workflow insurance-fnol --case conflicting-retry
node jextra-workflows.mjs test --workflow insurance-fnol --case review-context-change
# Runs individual action-boundary cases. No model or customer system is contacted.

These test commands exit 0 when their assertions pass, including expected denials. Exit 2 means a failed test; exit 1 indicates invalid input or a command error. Keep real evidence and test output in your own environment.

Agree the first implementation wave.

Bring the source system, first consumer, permitted action, acceptance cases and accountable owners. Start with a high-level brief and agree how private evidence will be inspected during scoping.