A read-only AI assistant that gets an answer wrong costs someone a few minutes. An AI agent that writes to your ERP, CRM, or billing system and gets it wrong can issue a second credit memo, close the wrong ticket, or change a record that belongs to another tenant. The model is rarely the only cause. The usual cause is a mutation path that was designed for a human clicking a button once, and is now being driven by software that retries, re-plans, and sometimes receives hostile instructions.
This guide answers one question for a Head of Engineering or VP of Engineering: what must be true before an AI agent is allowed to perform consequential write actions against enterprise systems? It is written for teams that already have an agent prototype and now face the harder decision of whether to let it act.
Three boundaries apply throughout. First, the framework below is a proposed design from the CIS Expert Team, not an industry standard and not a certification. Second, code is illustrative unless it is tied to an official API contract, and your target system's actual contract always wins. Third, standards are scoped to what they cover: an HTTP header draft says nothing about your message broker, and a tool annotation is a hint, not an enforcement mechanism.
For related ground, see our guides on idempotent webhooks and API retries and reconciling unknown-outcome operations. This article focuses on what is different when the caller is an agent.
Key Takeaways
- Bottom line: Allow an agent to write only when all eight go/no-go gates below are met. A single missing gate is a no-go for that action class, and no score or average can compensate for it.
- Agents retry by re-planning, not replaying. A new model call can produce different arguments, so the operation identity and approved payload must be created and stored outside the model.
- Bind identity to payload. Use a durable, tenant-scoped operation ID tied to an immutable hash of the approved payload. Reject the same ID with a changed payload. Treat a legitimately new intent as a new operation.
- A timeout is an unknown outcome, meaning completion could not be confirmed. It is not success and it is not verified failure. Reconcile against the authoritative system before any retry.
- Read-compare-then-write is not compare-and-swap. Require conditional mutation at the target, or disclose the serialization and conflict limits you accept.
- Acknowledge only what you verified. Say "done" after reading back authoritative state, and acknowledge inbound deliveries only after dedupe, durable recording, and work scheduling are atomic or explicitly recoverable.
- Identifiers are data. Operation IDs, customer references, and payload hashes can be sensitive. Name an owner, a retention rule, and an access policy.
Why Agent Write Actions Break the Assumptions Behind Enterprise Integrations
Key takeaway: Classic integration safety assumes a deterministic caller that replays the same request. An agent can regenerate the request, and can be manipulated into making one. Your controls must live below the model, not inside the prompt.
Most integration patterns were designed around a stable caller. A billing service that times out resends the identical request with the identical key. An agent works differently. After a timeout or a partial tool result, it may reason again and issue a call with a reworded memo field, a different amount rounding, or a different target record. To your downstream system, that is a new request, even though the business intent is the same.
There is a second difference: the instruction source. The OWASP project describes Excessive Agency (LLM06:2025) as the vulnerability that lets damaging actions occur in response to unexpected, ambiguous, or manipulated model output. It lists the root causes as excessive functionality, excessive permissions, and excessive autonomy, and it names hallucination and prompt injection as common triggers. In other words, your write path must be safe even when the model is wrong, and even when someone else is steering it.
What changes when the caller is an agent
| Dimension | Conventional service caller | Agent-driven caller | Implication |
|---|---|---|---|
| Retry behavior | Replays the same stored request | May regenerate a different request | Persist the approved request outside the model |
| Intent source | Deterministic code path | Natural language, retrieved documents, tool output | Untrusted content must never authorize a write |
| Failure surface | Network, validation, concurrency | All of those, plus ambiguity and manipulation | Add input-certainty and approval gates |
| Blast radius | Bounded by the service's code | Bounded by every tool and permission granted | Least privilege per tool and per user context |
| Audit question | What did the code do? | What was asked, approved, executed, and verified? | Keep a ledger that links all four |
If you are still defining the broader operating model for agents, our enterprise guide to AI agent governance covers ownership and lifecycle. This article narrows to the single moment of highest risk: the write.
How Most Organizations Approach It, and Why That Fails
Key takeaway: The common controls (prompt rules, tool hints, retry wrappers, vendor idempotency) are each useful but each leaves a specific gap. The gaps line up, which is why incidents get through.
Teams usually reach for five controls first. Each one is reasonable. None is sufficient alone.
- Prompt-level rules. "Never issue the same refund twice." This tells the model what you want. It does not stop a second call, a regenerated call, or a manipulated call.
- Tool annotations. The Model Context Protocol specification lets servers describe tool behavior, including hints about read-only, destructive, and idempotent behavior. As we read the specification, these are advisory metadata and clients are told to treat them as untrusted unless they come from a trusted server. Confirm the exact wording in the specification revision you implement. Either way, a hint describes a tool; it does not enforce anything.
- Generic retry wrappers. A decorator that retries on timeout is exactly the behavior that duplicates consequential writes when the first attempt actually landed.
- Relying on the vendor's idempotency feature. Some APIs do provide idempotency keys. Stripe's documentation on idempotent requests is a well-known example. But support, scope, retention windows, and behavior when parameters differ vary by vendor and endpoint. A vendor statement about one endpoint is not a guarantee about your whole path.
- Read-compare-then-write in agent code. The agent reads the record, checks that it looks right, then writes. Another actor can change the record between the read and the write. That is a race, not a compare-and-swap.
Where each common control stops
| Control | Where it lives | What it can do | What it cannot do |
|---|---|---|---|
| Prompt rule | Model context | Shape typical behavior | Prevent regenerated, injected, or repeated calls |
| Tool hint | Tool metadata | Help a client decide when to ask a human | Enforce anything, or be trusted from unknown servers |
| Retry wrapper | Client library | Recover from definite non-delivery | Distinguish "not applied" from "applied, response lost" |
| Vendor idempotency key | Target API | Deduplicate within the vendor's documented scope | Cover other endpoints, expired keys, or your own side effects |
| Read-compare-write | Agent code | Catch obvious staleness | Prevent concurrent changes between read and write |
The deeper failure is conceptual. Teams collapse three states into two. They treat "timed out" as "failed" and retry, or as "probably worked" and move on. The honest state is a third one: unknown. Everything in the next section exists to make that third state a first-class citizen.
A Proposed Design: Eight Go/No-Go Gates for Agent-Initiated Mutations
Key takeaway: This is a proposed design, not a method CIS claims as an established proprietary standard. Every gate is mandatory for an action class. Do not average them, weight them, or convert them into a readiness score.
The CIS Expert Team proposes the following eight gates as a pre-production review for any agent action that changes a system of record. Apply them per action class, not per agent. An agent may be cleared to update a ticket's priority while still being a no-go for issuing refunds.
These are necessary conditions. Passing all eight does not certify an agent as production-ready, does not establish regulatory compliance, and does not replace your own security, legal, and privacy review.
| # | Gate | Must be true | Evidence to request | No-go if |
|---|---|---|---|---|
| 1 | Scoped authority | Each tool has the minimum functions and permissions; actions run in the requesting user's or tenant's context; the downstream system authorizes every call | Permission matrix per tool; proof that authorization is enforced downstream, not by the model | The agent uses a shared high-privilege service account, or the model decides what is allowed |
| 2 | Input certainty and approved payload | Ambiguous or low-confidence inputs stop the action; high-impact actions need approval of the exact payload; approval binds to a hash | Schema validation rules; ambiguity handling tests; approval record containing the payload hash | A write can proceed on guessed entities, or approval covers a summary rather than the real payload |
| 3 | Durable operation identity | A tenant-scoped operation ID is created outside the model, stored durably, and bound to the immutable approved payload hash; the same ID with a changed payload is rejected | Ledger schema; conflict-rejection test; rule for minting new IDs for legitimately new intents | The ID is generated per model call, derived only from loosely matched text, or can be reused with different content |
| 4 | Atomic claim, record, and schedule | One worker wins the claim in a single atomic step; deduplication, durable recording, and work scheduling are atomic or explicitly recoverable before any delivery is acknowledged | Concurrency test with parallel workers; crash test between record and schedule | Two workers can execute the same operation, or an inbound event is acknowledged before it is durably recorded |
| 5 | Conditional mutation at the target | The target enforces version or precondition checks (for example an ETag with If-Match, or a version column in the update predicate), or you have disclosed the serialization and conflict limits | Target API contract; test that a stale version is rejected | The only protection is the agent reading first, comparing, and writing later, with no disclosure of the race |
| 6 | Outcome states and reconciliation | Success, definite rejection, and unknown are distinct; an unknown outcome is reconciled against authoritative state before any retry | State machine; reconciliation job; fault-injection results for lost responses | A timeout triggers an automatic retry of a consequential mutation without checking |
| 7 | Verified acknowledgment and terminal failure | The agent reports success only after reading back the postcondition; unresolved cases end in a named terminal state with a human owner | Read-back verification logic; terminal-state queue and runbook | The agent says "done" from a 2xx alone, or retries forever, or fails silently |
| 8 | Privacy and tenant ownership | Keys are namespaced by tenant; stored identifiers are minimized and treated as potentially sensitive; a named owner sets retention, access, and erasure handling | Data map for the ledger and logs; access policy; documented owner | Cross-tenant key collisions are possible, or nobody owns the ledger's privacy obligations |
How to use the table
Run the review as a working session with the agent team, the platform team, the owner of the target system, and whoever owns data privacy. For each action class, mark each gate as met with evidence, not met, or not applicable with written reason. One "not met" is a no-go for that action class. Remediate or downgrade the action to propose-only, where the agent drafts and a human executes.
For quality teams, the fault-injection side of these gates pairs well with the drills in our integration failure testing guide.
Engineering the Mutation Path: Operation Ledger, Atomic Claims, and Conditional Writes
Key takeaway: Put a small, boring, durable ledger between the agent and every system of record. The model proposes; the ledger decides whether an operation exists, who owns it, and what state it is in.
The operation ledger
When a human or a deterministic policy approves an action, your platform (not the model) creates an operation record. It holds the tenant, a unique operation ID, the hash of the canonicalized approved payload, the approver, and a status. The approved payload itself is stored where it cannot be edited. Every later attempt reads that stored payload rather than asking the model to produce it again.
The example below is illustrative, written in PostgreSQL-flavored SQL. It is not an official API contract for any product. Adapt it to your datastore's actual transaction and concurrency semantics.
-- Illustrative only: adapt to your database and target API contract CREATE TABLE agent_operation ( tenant_id text NOT NULL, operation_id uuid NOT NULL, payload_sha256 bytea NOT NULL, approved_by text NOT NULL, status text NOT NULL DEFAULT 'approved', lease_owner text, lease_expires_at timestamptz, fencing_token bigint NOT NULL DEFAULT 0, target_ref text, PRIMARY KEY (tenant_id, operation_id) ); -- 1) Register the approved action once. A duplicate registration is a no-op. INSERT INTO agent_operation (tenant_id, operation_id, payload_sha256, approved_by) VALUES ($1, $2, $3, $4) ON CONFLICT (tenant_id, operation_id) DO NOTHING; -- Then, in the same transaction, compare the stored hash. A different hash -- under the same id is a conflict: reject it. Never overwrite the approved payload. -- 2) Atomically claim work. Only one worker can win this single statement. UPDATE agent_operation SET status = 'claimed', lease_owner = $3, lease_expires_at = now() + interval '60 seconds', fencing_token = fencing_token + 1 WHERE tenant_id = $1 AND operation_id = $2 AND status = 'approved' RETURNING fencing_token; -- Zero rows returned: another worker owns it, or it is already settled.Three design choices matter here. The primary key includes the tenant, so one tenant's operation ID can never collide with another's. The hash comparison is what turns "same key, different payload" into a rejected conflict rather than a silent overwrite. And the claim is a single conditional update, not a read followed by a write, so two workers cannot both believe they won. Note that claims only start from approved. An expired lease does not return the operation to approved, because the previous worker may have already sent the request. Expired leases move to unknown and go through reconciliation.
The execution flow
The pseudocode below uses hypothetical function names. Replace them with the real client calls for your target system and confirm each error category against that system's documented behavior.
# Illustrative pseudocode, not an official SDK contract def run_operation(tenant_id, operation_id, worker): token = claim(tenant_id, operation_id, worker) # the single UPDATE above if token is None: return # not ours: do nothing op = load_operation(tenant_id, operation_id) request = op.approved_request # stored, never re-generated by the model assert sha256(canonical_json(request)) == op.payload_sha256 try: response = target.apply( request, if_match=op.expected_version, # target-side conditional write external_ref=str(operation_id), # lets us look the action up later ) except DefinitelyNotApplied as e: # e.g. validation error, 403, 412 settle(tenant_id, operation_id, token, 'rejected', reason=e.code) return except (Timeout, ConnectionLost): # request may or may not have landed settle(tenant_id, operation_id, token, 'unknown') schedule_reconcile(tenant_id, operation_id) # never blind-retry from here return observed = target.read(op.target_id) # read back authoritative state if postcondition_holds(observed, request): settle(tenant_id, operation_id, token, 'succeeded') else: settle(tenant_id, operation_id, token, 'unknown') schedule_reconcile(tenant_id, operation_id)Every settle call should be conditional on the fencing token, so a slow worker whose lease expired cannot overwrite the result of whoever took over.
Observed outcomes and what is allowed next
| What you observed | Ledger state | Meaning | Allowed next step |
|---|---|---|---|
| Success response, read-back matches | succeeded | Completion verified | Acknowledge to the user or upstream trigger |
| Success response, read-back does not match | unknown | Completion could not be confirmed | Reconcile; do not report success |
| Validation, authorization, or precondition failure | rejected | Verified not applied | Re-plan with a new approval, or stop |
| Timeout, dropped connection, expired lease | unknown | Completion could not be confirmed | Reconcile against authoritative state first |
| Reconciliation finds the effect, tied to this operation | succeeded | Applied, response was lost | Acknowledge; no retry |
| Reconciliation positively confirms absence under safe conditions | approved (eligible to retry) | Verified not applied | Retry with the same operation ID |
| Reconciliation is inconclusive after bounded attempts | needs_human | Terminal for automation | Human owner decides; record the decision |
Reconciliation and its limits
Reconciliation means asking the authoritative system what actually happened, usually by looking up the operation's external reference or by reading the record's current state and history. It works only when the target gives you something to look up. If the target offers no lookup by reference, no audit trail, and no idempotency support, an unknown outcome can only be resolved by a human. Say so in the design review instead of hoping retries will be safe.
Also be careful with "absence". A record not being there now does not prove the request will not land later if it is still queued or in flight. Safe options are a target-side idempotency mechanism honoring the same key, a fencing or version check at the target, or waiting beyond the target's documented maximum processing window before concluding absence. If none is available, the action stays human-resolved.
Inbound events that start agent work
Many agent runs begin with a webhook or queue message. The same discipline applies on the way in: deduplicate the event, record it durably, and schedule the work in one atomic step, or in steps that are explicitly recoverable, before you return a success acknowledgment to the sender. Acknowledging first and recording later means a crash loses the event. Our guides on evaluating vendor webhook delivery guarantees and on idempotent webhooks go deeper on this half of the problem.
Conditional writes versus read-then-write
HTTP gives you a standard mechanism for target-side preconditions. RFC 9110 (HTTP Semantics) defines conditional requests, including If-Match against an entity tag, so a server can refuse an update when the resource has changed. Database equivalents include a version column in the WHERE clause of an update. The key property is that the target evaluates the condition atomically with the write. If your target does not offer anything like this, the fallback is to serialize all writes to a given record through a single-writer queue and to write down the residual risk: any actor that bypasses your queue, such as a human in the native UI, can still race you.
Why This Fails in the Real World
Key takeaway: Capable teams fail here because ownership is split across the agent team, the platform team, and the system owner, and each assumes another one handles the hard cases. These are system gaps, not individual mistakes.
The scenarios below are illustrative composites that show common failure mechanics. They are not reports of specific client engagements, and no outcomes are claimed.
Scenario 1: The regenerated retry
An agent issues a credit memo for a billing dispute. The call times out. The framework treats the timeout as a failed tool call and returns the error to the model, which reasons again and calls the tool a second time with a slightly different description and a freshly generated request ID. The first call had in fact succeeded. The billing system sees two valid, distinct requests.
Why intelligent teams still miss it: the retry logic was tested with a mocked failure that never reached the target. The idempotency key was generated per tool call, which is correct for a conventional service and wrong for an agent. Nobody owned the question "who creates the identity of a business action?" Gates 3 and 6 close this gap.
Scenario 2: The legitimate second operation that vanished
To avoid duplicates, a team derives the deduplication key from customer ID plus action type. It works in testing. In production, a customer legitimately receives a second credit two weeks later. The system treats it as a duplicate, skips it, and the agent tells the user the credit was issued, because a "deduplicated" response looked like success.
Why it happens: deduplication was designed to prevent repeats but not to distinguish a repeat of the same intent from a new intent. The agent also acknowledged from a status code rather than verifying the outcome. Gates 3 and 7 address this: new approved intents mint new operation IDs, and acknowledgment follows read-back verification.
Scenario 3: The shared cache in a multi-tenant platform
A SaaS vendor adds an agent feature to a multi-tenant product. Idempotency records are cached under the key the client supplies. Two tenants' integrations both use short sequential identifiers. One tenant's request returns a stored response that belongs to another.
Why it happens: uniqueness was assumed to be global, and tenant scoping was a convention rather than a constraint. Gate 8 requires the tenant in the key and in the authorization check, and requires tests for cross-tenant collisions.
Scenario 4: The race with a human
The agent reads an order, sees it is eligible for modification, and updates it. Meanwhile a customer service representative has just canceled it in the native UI. The update revives a canceled order. The agent's read-compare-then-write looked careful, but the target never checked the version.
Why it happens: the integration exposed a plain update endpoint, and nobody asked whether the target supported preconditions. Gate 5 forces that question before launch.
The common root causes
- Happy-path testing. Fault injection that drops the response after the target commits is rarely run.
- Unowned seams. The agent team owns prompts, the platform team owns retries, the system owner owns the API, and nobody owns the idempotency contract across all three.
- Vocabulary gaps. "Failed" and "unknown" are used interchangeably in dashboards and incident reports.
- Trusting a green status. A 2xx means the request was accepted under the target's semantics, which may not match your business postcondition.
Risks, Constraints, and Trade-Offs: Standards Scope, Privacy, and Latency
Key takeaway: The controls cost latency, engineering effort, and approval friction. Standards help only inside their scope. And the ledger you build to be safe becomes a new store of sensitive data that needs an owner.
Scope each standard to its transport and use case
- Idempotency-Key header. The IETF HTTP API working group is developing the Idempotency-Key HTTP Header Field as an Internet-Draft. It is work in progress, not a published RFC, and the IETF itself says drafts should not be cited as reference material other than as work in progress. It applies to HTTP requests. It says the key must not be reused with a different request payload, that resources define their own expiry policy, and that a client cannot assume a server will respect the header without prior knowledge. It does not govern message brokers, database writes, or an agent's internal tool protocol unless you map those onto HTTP yourself.
- HTTP method semantics. RFC 9110 defines idempotent methods such as PUT and DELETE in terms of the intended effect of repeated identical requests. That does not make a retry safe if the resource changed between attempts, for example a DELETE repeated after the record was recreated by someone else.
- OWASP LLM guidance. The Excessive Agency entry gives security principles such as minimizing extensions, minimizing permissions, requiring user approval for high-impact actions, and complete mediation. It is guidance, not a test suite, and it does not define your idempotency design.
- NIST AI Risk Management Framework. The NIST AI RMF is a voluntary framework for managing AI risk. It can structure your governance conversation. It does not prescribe mutation controls.
Vendor claims, compliance support, and your obligations
Keep three categories apart. A vendor statement says what a product does, such as supporting idempotency keys on certain endpoints. A compliance-support feature such as audit logging helps you meet an obligation but does not meet it for you. A reader-specific legal obligation, for example under privacy, financial, or sector regulation, depends on your jurisdiction, data, and contracts, and needs your counsel. Read primary documentation and contracts, and test behavior rather than relying on a summary.
Identifiers can be sensitive data
An operation ledger feels like plumbing, but it often contains customer references, record identifiers, approver identities, timestamps, and payload hashes. Combined, these can reveal who was affected and what was done. A hash of a small input space, like an email address or a short account number, can be reversed by guessing. Treat the ledger and its logs as personal or confidential data where applicable.
Name one accountable owner for the ledger's privacy: who decides what is stored, how long, who can read it, and how deletion or erasure requests interact with audit and dispute needs. That is a policy decision with legal input, not a purely technical one. Our guide on privacy governance for integration event logs covers this in detail.
Trade-offs to decide on purpose
| Trade-off | Cost of the control | Cost of skipping it | Reasonable position |
|---|---|---|---|
| Human approval of exact payloads | Reviewer time; approval fatigue if overused | Manipulated or mistaken actions execute | Require it for irreversible or high-value classes; relax only with evidence |
| Read-back verification | Extra call and latency per action | False "done" reports | Always for consequential writes |
| Ledger and claims | Extra datastore, operational ownership | Duplicates and untraceable actions | Treat as shared platform infrastructure, not per-agent code |
| Conditional writes | May require target API changes or a wrapper | Lost updates and revived records | Negotiate with the system owner early; disclose any fallback |
| Single-writer serialization fallback | Throughput limits; bypass risk | Concurrent overwrites | Accept only with a written residual-risk statement |
| Key and ledger retention | Storage and privacy exposure | Late retries can no longer be recognized | Retain at least as long as the longest possible retry and dispute window, as decided by the named owner |
A Lower-Risk Path: Rollout, Persona Guidance, and the Decision Checklist
Key takeaway: Earn autonomy in stages. Start with propose-only, move to human-approved execution through the ledger, and grant bounded autonomy only to reversible, low-value action classes that pass all eight gates.
Three options compared
| Dimension | A: Read-only copilot | B: Human-approved writes through the ledger | C: Autonomous writes |
|---|---|---|---|
| Speed to value | Fast | Moderate; ledger and approval UX required | Slowest to make safe; fastest at runtime |
| Cost | Lowest | Moderate: shared platform component plus integration work | Highest: B plus extensive fault-injection and monitoring |
| Risk | Low, confined to wrong answers | Controlled; approver is a safeguard but can fatigue | Highest; depends on every gate holding |
| Scalability | High | Limited by reviewer capacity | High, if gates hold under load |
| Hidden failure mode | Users copy answers into systems by hand, unaudited | Rubber-stamp approvals without payload review | Silent duplicates or missed updates from an unknown outcome treated as success |
| Fits when | Value is mostly retrieval and drafting | Actions are consequential or irreversible | Actions are reversible, low-value, and well-instrumented |
A staged rollout
- Shadow mode. The agent proposes actions; humans execute them as usual. Compare proposals to what people actually did. This builds evidence for gate 2 without touching production data.
- Ledger with human execution trigger. Approvals create operations; a deterministic worker executes. Run fault injection on lost responses, duplicate deliveries, parallel workers, and stale versions.
- Bounded autonomy. For action classes that pass every gate and are reversible, allow execution without per-action approval, with rate limits and monitoring. OWASP notes that logging, monitoring, and rate limiting limit the damage but do not themselves prevent excessive agency, so keep the preventive gates in place.
- Review on change. A new tool, a new target API version, a new permission, or a new model version reopens the relevant gates.
An illustrative sizing exercise
This is a hypothetical example to show why unknown outcomes need a real path, not a measurement from any client. Suppose an agent performs 2,000 consequential updates per day and 0.5 percent of them end in an ambiguous timeout. That is about 10 unknown outcomes every day. If your design treats unknowns as failures and retries, you may create up to 10 duplicates daily. If it treats them as successes, you may leave up to 10 actions undone while telling users they are complete. Either way, a human team has to find them later. With a ledger and reconciliation, most of these resolve automatically and the remainder land in a named queue. Use your own timeout rate, volume, and cost per correction to size the effort.
What a Head of Engineering should do differently
- Stop asking whether the agent is accurate enough, and start asking which action classes pass the eight gates.
- Make operation identity a platform capability owned by one team, not a pattern each agent reinvents.
- Require that dashboards show unknown as its own state with an age and an owner.
- Put the system owner of each target in the design review before the first line of agent code.
- Schedule a fault-injection drill that drops responses after commit, before any new action class goes live.
2027 Update: What is moving, and what is not
The Idempotency-Key draft continues to evolve: revision 08 was published in October 2026 with an expiry in April 2027, and it remains an Internet-Draft. Agent tool protocols and their metadata conventions are also changing. The OWASP LLM list was last revised as the 2025 edition at the time of writing. Check each source's current version before you rely on a specific clause.
What does not change is the structure of the problem. Any caller that can retry will eventually create ambiguous outcomes. Any caller that can be misled needs authorization enforced downstream. Any system that records identifiers needs a privacy owner. If you design to those facts, specific headers and protocols become implementation details you can swap.
Want an independent read on your agent's write path?
Bring one action class, such as refunds, order changes, or ticket closures, and walk through the eight gates with engineers who have seen these failures before.
Explore how CIS AI-enabled engineering teams can review and harden your agent mutation path.
Request Free ConsultationFor background on the surrounding capability, see our overview of AI agents and enterprise automation, our AI agent development services, and our approach to API governance and architecture.
Conclusion: Five Actions Before an Agent Writes to a System of Record
The goal is not to make agents timid. It is to make every write attributable, repeatable without duplication, and verifiable. These five actions turn the guidance above into a decision.
- Inventory action classes. List every write your agents can perform, mark each as reversible or irreversible, and set the ones that are irreversible to propose-only until they pass all eight gates.
- Move identity out of the model. Create operation IDs and approved payload hashes in your platform, scoped by tenant, and make changed-payload reuse a hard rejection.
- Make unknown a real state. Add it to your state machine, dashboards, and runbooks, and forbid blind retries of consequential mutations until reconciliation has run.
- Check the target, not the vendor summary. Confirm conditional-write support, idempotency scope, and retention windows in the primary documentation, then test them. Where support is missing, write down the serialization limits you accept.
- Assign owners. Name who owns the ledger's privacy, who resolves terminal cases, and who reopens the gates when tools, permissions, or model versions change.
About the Authors
Cyber Infrastructure (CIS) is a software development and digital transformation company founded in 2003, serving clients across the USA, EMEA, and Australia with an in-house engineering model. CIS states that its delivery practices are CMMI Level 5 appraised and ISO 27001 certified, with SOC 2-aligned controls. Ask us for current certificates and their scope before relying on them in your own vendor assessment. This article was reviewed by the CIS Expert Team.
Frequently Asked Questions
What is the safest way to let an AI agent change records in an ERP or CRM?
Put a deterministic layer between the agent and the system of record. The layer should:
- Create a tenant-scoped operation ID outside the model.
- Bind that ID to a hash of the approved payload.
- Atomically claim the work so only one worker executes it.
- Use conditional writes at the target where available.
- Verify the result by reading back state before reporting success.
Pair this with least-privilege permissions and human approval for high-impact actions.
Is it safe to retry an agent's tool call after a timeout?
Not blindly. A timeout means completion could not be confirmed. The request may have been applied, rejected, or never delivered. For consequential mutations, reconcile against the authoritative system first, for example by looking up the operation's external reference. Retry with the same operation ID only when the action is verified not applied, or when the target honors an idempotency mechanism you have confirmed.
Does the Idempotency-Key HTTP header solve duplicate agent actions?
Only partly. It is an IETF Internet-Draft, which is work in progress and not a published RFC, and it applies to HTTP requests. The draft states the key must not be reused with a different payload and that clients cannot assume a server honors it. It does not cover message brokers, internal tool protocols, or your own side effects, and each API defines its own expiry policy.
How should operation IDs be scoped in a multi-tenant system?
Include the tenant in the primary key of the operation record and in the authorization check, so the same identifier from two tenants can never collide or return another tenant's result. Add a test that submits identical IDs under different tenants. Take the tenant from authenticated context, never from model output.
What is the difference between a retry and a new operation?
A retry repeats the same approved intent and reuses the same operation ID and payload. A new operation reflects a new approved intent, such as a second legitimate credit two weeks later, and gets a new ID. If the same ID arrives with a different payload, reject it as a conflict rather than treating it as either one.
Why is read-compare-then-write not enough for concurrency safety?
Because another actor can change the record between your read and your write. Real compare-and-swap requires the target to evaluate the condition atomically with the write, such as an ETag with If-Match or a version check in an update predicate. If the target cannot do this, serialize writes through a single writer and disclose the residual risk, since bypassing actors can still race you.
Do MCP tool annotations make a tool safe to call repeatedly?
No. As we read the specification, annotations such as idempotent or destructive hints are advisory descriptions, and clients are told to treat them as untrusted unless they come from a trusted server. Verify the wording in the specification revision you use. Enforcement must happen in your own authorization, ledger, and target-side checks.
Who should own the privacy of an operation ledger?
One named accountable owner, usually in data governance or the platform team with privacy and legal input. The owner decides what is stored, retention periods, access rules, and how erasure requests interact with audit and dispute needs. Operation IDs, customer references, and hashes of small input spaces can all be sensitive.
Is your agent ready to touch a system of record?
Duplicate credits, revived orders, and "done" messages nobody verified are design problems you can find before launch.
Talk to CIS engineers about reviewing your agent's mutation path, ledger design, and failure drills.
Request Free ConsultationAi-agent-development-services
This article is most relevant for technology and digital-transformation leaders who need to roll out a practical technology solution. Use the related CISIN path to compare delivery options, implementation fit, risk, and practical next steps.
Reviewed for technology and business decision makers
This guide is reviewed for clarity, technical and operational relevance, service alignment, and a useful next step.
Validate legal, security, data, budget, and operational requirements with the relevant stakeholders before rollout.
