Putting AI Agents Into Production Without Surrendering Control

A customer reports being charged twice. An AI agent reads the message, locates the account, compares the invoice with the payment record, prepares a credit memo, and queues a refund. What looks like one smooth customer-service interaction is actually a chain of privileged operations across email, CRM, billing, and a payment platform.

That chain is where the risk profile changes. A model that drafts a poor reply creates a review problem. An agent that acts on a poor conclusion can change a balance, disclose a record, or send money. Once a system can use tools, the central question is no longer whether its answer sounds correct. The question is what authority it has, how that authority was delegated, and whether the organization can stop the transaction before a bad decision becomes a business event.

Agency starts at the system boundary

The market uses “agent” for everything from a search assistant to software that plans and executes a multi-step job. The label does not help a security review. Reach does. Which records can the system read? Which states can it change? Can it contact an external party? How many steps may it take before a person must make a new decision?

Those questions separate a conversational feature from an operational actor. A support copilot may suggest a response that an employee can edit. A production agent may open a case, change its classification, issue a credit, and notify the customer without returning to the original screen. The language model contributes judgment, but the connected tools create the real-world power.

Traditional role-based access control still matters, but copying a broad human role onto an agent is usually the wrong starting point. A billing specialist receives context, training, and accountability that a probabilistic system does not possess. A standing “billing specialist” token can therefore give an agent far more reach than the current task requires.

Give the agent a warrant, not a master key

In 2026, NIST elevated software and AI agent identity and authorization into a dedicated standards effort. Its concept paper asks how an agent should be identified, how it can prove authority for a specific action, how delegated access should work, and how the resulting activity can be tied back to human authorization.

A production design begins by giving each agent its own non-human identity. The agent should not borrow an employee's full browser session or share one permanent service account with unrelated automations. Every run should carry a short-lived grant that states who or what initiated the task, the business purpose, the resources in scope, and when the grant expires.

For the duplicate-charge case, the grant might cover one customer, one invoice, a maximum amount, and two allowed operations: create a draft credit memo and submit a refund for approval. It would not authorize a customer export, a banking-profile change, or access to every open invoice. That is least privilege expressed at the level of a business transaction rather than an application menu.

Approval must travel with the exact action. Consent for a $52.40 refund cannot become authority for $5,240 or for a different recipient. A useful approval envelope binds the agent identity, tool, parameters, case identifier, approver, and expiration time. If any material field changes, the old approval no longer applies.

Tool interfaces are policy boundaries

Agent platforms commonly expose functions such as “find customer,” “load invoice,” “send email,” or “issue payment.” Clear tool descriptions improve planning, but they are not access controls. The receiving service must validate every call as if the model's explanation were absent.

Write-capable tools should accept narrow, structured input. They need server-side ranges, state-transition rules, ownership checks, and destination restrictions. A general-purpose SQL tool or an endpoint that accepts natural-language instructions turns application logic into a suggestion. A purpose-built operation such as “create refund draft for invoice X, up to amount Y” is easier to authorize, test, observe, and revoke.

Read and write paths deserve separate tools even when they appear in the same workflow. The agent may first collect invoice facts through a read-only adapter. A second adapter, protected by stricter policy, creates the draft. That separation makes permission review clearer and records the point at which research became an action.

Tool discovery also needs control. An agent should not gain new capabilities simply because another server announces them at runtime. Production environments need an approved inventory, pinned versions, ownership information, and a defined process for adding or removing tools. Otherwise, a supply-chain change can quietly expand the agent's authority.

Untrusted content can redirect a trusted workflow

Direct prompt injection is obvious enough: a user tells the model to ignore its rules. Indirect injection is easier to miss because the instruction arrives inside material the agent was expected to read. It may be hidden in an email, PDF, ticket, web page, or retrieved knowledge record. The agent sees language in its working context even though the organization never approved that language as an instruction.

OWASP's 2026 guidance for agentic applications calls out goal hijacking, tool misuse, identity and privilege abuse, supply-chain compromise, and unexpected code execution. Its 2026 incident review goes further: many failures are no longer model-only defects. They involve overprivileged identities, orchestration layers, external tools, and data paths that were trusted too broadly.

No system prompt can serve as the only barrier between an untrusted attachment and a sensitive API. In the refund example, an invoice attachment must never expand permissions. If hidden text asks the agent to send a customer list to an outside address “for verification,” the mail and export services must refuse the request. External destinations should be allowlisted, sensitive fields minimized, and content provenance carried into every policy decision.

Some sources warrant a restricted mode. The agent can extract facts and prepare a reviewable recommendation, but write tools remain unavailable until trusted data confirms the case. This is less convenient than universal autonomy. It is also much easier to defend.

A human click is not automatically meaningful oversight

“Human in the loop” is often treated as a complete safeguard. It is not. A person cannot approve responsibly if the interface shows only a confident summary generated by the same system requesting permission. The review screen should expose the effective transaction: customer, amount, destination, account, invoice, tax treatment, and source records.

Once approved, that payload must be immutable for the execution attempt. If a price is recalculated, a bank account changes, or the agent selects a different record, the system must ask again. This closes a common time-of-check, time-of-use gap between what the person saw and what the service ultimately received.

Approval requirements should follow impact. Saving an internal draft is not equivalent to releasing funds. Organizations can define action classes with automatic limits, single-person approval, dual control, or a complete prohibition. The model may recommend a class, but it should not set its own guardrails.

Audit the intent, the decision, and the result

Conventional API logs may show that an endpoint returned 200. That is insufficient for an agent that took several steps based on changing context. An investigation needs to connect the original assignment, source material, model and policy version, tool request, authorization decision, human approval, and final business outcome.

A shared correlation identifier can link those records without copying every customer document into a telemetry platform. Logs still require data minimization, access separation, tamper protection, and retention limits. In many cases, a durable reference or content hash is enough, while the original personal data remains in the system designed to protect it.

Useful monitoring also looks beyond uptime. Repeated policy denials, frequent requests for broader access, a new external destination, or a spike in human corrections may reveal a boundary problem before task-completion metrics do. Teams should be able to answer not only “Did the run finish?” but also “How close did it come to doing something it was not allowed to do?”

Retries are business operations, not network details

Multi-system workflows fail in awkward places. A payment platform may complete a refund and time out before returning confirmation. If the agent simply retries, the customer could receive the money twice. Every state-changing operation therefore needs an idempotency key derived from the business case and retained across technical attempts.

The broader workflow should be modeled as an explicit state machine. A credit memo may be proposed, approved, submitted, accepted, or rejected. Those states are not interchangeable, and they should not be inferred from conversational memory. Durable state allows a worker to resume safely after a restart and lets an operator see what has actually happened.

Compensation must be designed before deployment. Some actions can be reversed; others can only be followed by a corrective action. An email cannot be unsent. A reserved payment may be canceled. A customer-facing status change might require a new record rather than deletion. The agent needs a defined path for each case instead of improvising a cleanup plan.

An operational kill switch is equally concrete. It must block new steps, stop queued work at controlled checkpoints, and revoke delegated credentials. A button that changes a dashboard label while background workers continue is not a kill switch. Teams should test the stop path with the same seriousness as the happy path.

Expand autonomy in measured stages

A useful pilot is common enough to produce evidence, narrow enough to contain impact, and already has a manual fallback. The organization can then expand authority in five deliberate stages:

1. Shadow mode: The agent evaluates real cases, but its output causes no action. Teams compare its choices with the human process.
2. Read-only operation: It assembles records and explains the case without access to write tools.
3. Draft mode: It creates emails, credit memos, or status changes as drafts for review and submission.
4. Bounded execution: Low-impact actions may run within strict limits. Anything outside those limits requires approval bound to the payload.
5. Targeted autonomy: Only well-understood case types earn unattended execution after the earlier stages produce reliable operating evidence.

Promotion should depend on more than accuracy. Track human overrides, permission denials, duplicate attempts, compensating actions, policy exceptions, and time to stop a run. A system that completes many tasks but regularly reaches for unnecessary privileges is not ready for greater autonomy.

Transparency is a separate control plane

The European Union's Article 50 transparency obligations began applying on August 2, 2026. They address, among other situations, notice when people interact directly with certain AI systems and marking or disclosure requirements for certain AI-generated or manipulated content. The European Commission published implementation guidelines in July 2026.

Those duties do not replace technical authorization. A clearly disclosed agent can still have excessive access, while a tightly constrained internal agent may still trigger a transparency requirement in a customer-facing process. Legal scope and operational authority need separate analysis, followed by one coherent implementation.

For public-interest text, human review and editorial control can also affect the applicable disclosure analysis. The practical answer is not merely a badge. It is a record of who reviewed the material, what changed, and which version was released. That same discipline improves incident response and content governance even when a specific labeling duty does not apply.

Start with one uncomfortable question

Teams often begin by asking what an AI agent could automate. A stronger production question is narrower: Which single business action may this system perform, under exactly what conditions? Once that is answered, the required identity, tools, approval, telemetry, and recovery path become much easier to specify.

An agent is not production-ready because it can complete ten impressive steps in a demo. It is production-ready when an unexpected eleventh step cannot turn into unbounded authority. The most capable enterprise agent is therefore not the one connected to every tool. It is the one whose permitted effect is explicit, enforced by the surrounding systems, and understandable after the fact.