Review one consequential operation
This checklist is for an agent or automation that will change external state. Apply it to one concrete operation, not to “AI readiness” in general. Use it as a review sheet with the platform owner, security reviewer and native-system owner.
This is an engineering framework, not a security certification or numerical maturity benchmark. An unchecked item identifies work or a documented accepted limit; completing the sheet does not prove the business decision is correct.
1. Name the operation
- State the exact intended effect and the native system that owns it.
- Identify one accountable owner and the reason this workflow needs automation.
- Separate the agent’s recommendation from the authority to execute it.
- Define what a successful native response establishes: admission, commitment, convergence or something else.
- Record what the operation does not establish, including application health where relevant.
2. Bound authority
- Identify the verified principal and accepted delegator.
- Bind the exact target, parameter set, expiry and quantity/task limits.
- Confirm that a new session, sub-agent or request key cannot unintentionally reset the intended limit.
- Describe when human review is required and which command the decision binds.
- Define revocation behavior before and after possible native dispatch.
3. Inspect the write path
- Identify the credential-holding writer and native permissions.
- Review alternative credentials, Secrets, exec paths, CI jobs and other tools.
- Confirm native RBAC, admission and controller ownership.
- If GitOps owns desired state, decide whether the authoritative change belongs in Git rather than an out-of-band mutation.
- Document trusted components that remain outside the prevention claim.
4. Freeze the native baseline
- Resolve current resource identity independently of the agent’s cached context.
- Bind relevant native versions and operation-specific preconditions.
- Refuse stale or replaced resources under the contract.
- Identify properties that cannot be checked atomically with the target mutation.
- State which assumptions need application-owner review, such as schema compatibility.
5. Preserve operation identity
- Record the operation before possible external effect.
- Preserve the same logical identity across retries and worker restarts.
- Reject changed payloads under a reused identity.
- Use the native writer’s documented idempotency and conditional-update semantics.
- Identify the last durable point before a request may have been sent.
6. Define uncertainty and recovery
- Distinguish known rejection from a timeout after possible dispatch.
- Specify what evidence can establish the original effect.
- Test insufficient history, not only successful reconciliation.
- Assign an owner and escalation path for unresolved outcomes.
- Define which capacity or resource reservations remain held while commitment is unknown.
- Treat compensation as a new authorized action rather than erasing history.
7. Test the failure matrix
| Test | Evidence to retain |
|---|---|
| Out-of-scope target | Refusal before native mutation |
| Changed input under the same request key | Binding conflict, original operation preserved |
| Revoked grant | Documented refusal or already-dispatched limitation |
| Concurrent native edit | Conditional-update result and unchanged approval meaning |
| Worker crash | Durable operation and attempt state after restart |
| Native response lost | Honest commit classification; no invented failure |
| Native history missing | Continued uncertainty and escalation |
| Committed change, degraded service | Separate commitment, observation and health conclusions |
8. Compare with the existing stack
Measure the current stack and any proposed runtime against the same operation and cases. Record setup work, review burden, exception frequency, operator investigation, retained evidence and ongoing ownership. Do not treat a successful demo as proof of lower operating cost.
Use the existing stack if it satisfies the contract economically. Add a component only for a meaningful missing capability or integration burden. If the operation itself has little value, automate something else—or retain the existing workflow.
Where this framework comes from
The research report synthesizes first-party enterprise research and technical documentation. The checklist draws particularly on OWASP’s excessive-agency guidance, Kubernetes API semantics, Stripe’s error-handling guidance and Temporal’s Activity idempotency guidance.
For a concrete worked contract, read the technical note and Kubernetes rollback page. The browser’s print function produces a reusable review sheet; no assessment answers are collected by this page.