Control Before Trust: Putting Agents Into Production

The pilot goes well. The agent finds root causes your team agrees with, faster than your team finds them. Then the proposal reaches the risk committee, and the first question isn't about accuracy. It's this: if the agent does something wrong at 3 a.m., can we see it, limit it and stop it?

If the answer is a pause, the project stalls there. In my experience, that's where most agent projects stop, long before accuracy becomes the issue.

The previous part of the Agentic IT Operational Excellence series showed what agents on a unified layer can do with the payments incident. This part is about the condition that comes first. Before an agent can earn trust in production, the controls around it have to exist.

Why agent projects stall at the pilot

Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. Deloitte found that only 11% of organizations have agentic systems ready for production.

All three of Gartner's reasons are about how agents are deployed and governed. None is about whether the model can reason. Cost and business value get their own part later in this series. This part takes the third reason, because it's the prerequisite: until the risk is under control, an organization can't give an agent enough access to create any value.

The control gap, in numbers

Security surveys show how wide the gap is.

01Identity

92%

of 235 enterprise CISOs and CIOs lack full visibility into agent identities.

02Containment

95%

are unsure they could detect or contain a compromised agent.

03Own identity

22%

of teams manage an agent as an identity of its own. The rest share API keys.

04Stop

35%

of leaders admit they cannot immediately stop an agent that misbehaves.

In a 2026 Cloud Security Alliance survey of 235 CISOs and CIOs at large enterprises, 92% said they lack full visibility into agent identities, and 95% weren't sure they could detect or contain a compromised agent. Gravitee found that only 22% of teams manage an agent as an independent identity; the rest still use shared API keys (vendor-run survey). And in WRITER's survey, 35% of leaders admitted they couldn't immediately stop an agent that was behaving badly (vendor-run survey).

The implication for anyone running operations is plain. An agent you can't trace, can't scope and can't stop on demand won't get past a risk committee, however accurate it is. In my experience, the organizations that succeed design the controls before they grant the first access. Not after the first incident.

Six risks, six controls

This is the table I'd use as the evaluation framework, for any vendor including us.

Table 1. Risks of putting agents into production, and the matching controls.

Read the right-hand column as a list of questions. Who issues the credential, and when does it expire? Where does the agent run? What does the model actually see? Can you name which agent took an action and who approved it? Who can stop it, and how fast? Each row should have an answer you can demonstrate, not describe.

Every action goes through a gateway

The controls in that table come together in one architectural rule: the agent never touches a system directly.

01Agent

Isolated sandbox

Does its work in isolation and holds no credentials of its own.

02Secure gateway

Identity, policy, approval, log

Verifies who is acting, applies policy, issues credentials just in time, records every step.

03Systems

Cloud, observability, code, apps

Receive only the actions the gateway allowed, with scoped, short-lived access.

The agent works in an isolated sandbox and holds no credentials. When it needs to act, the action goes through a secure gateway. There, the agent's identity is verified, policy is applied, a credential is issued just in time for that one task, and every step is logged. Only then does the action reach your cloud, observability, code or applications.

That rule is what limits the damage of a prompt injection hidden in a log line. The agent can be fooled into asking. The gateway decides whether the request is allowed, and the connection's own permissions set the outer limit.

In CloudThinker, agents run in a Sandbox, changes go through Auto Mode, and access is set by Connections. We've written up each piece separately:

• How access and keys are kept away from the agent: The Agent Never Holds Your Keys.
• How secrets and personal data are kept from the model: What Never Reaches the Model.
• How every agent action is recorded: A Receipt for Every Action.
• How approval decides what runs alone: Auto Mode.

These controls match where guidance is heading

None of this is a vendor's private opinion. The 2026 Singapore Consensus on Global AI Safety Research Priorities sets out ten principles for managing agentic risk. They include least privilege, traceable identity, auditability, interruptibility and human oversight. Every one of them shows up in Table 1.

Four data questions to ask any vendor

Before a pilot starts, a CIO should get clear answers to four questions about data:

1. Where is the data stored?
2. Is it used to train a shared model?
3. Which models can access it?
4. Can you export all the knowledge and logs if you stop using the product?

The fourth one is the easiest to forget. Company memory is the point of this whole approach. If you can't take it with you, you don't own it.

For regulated companies in Vietnam

For companies operating in Vietnam, those four questions connect directly to legal obligations. This is the context I'd brief a risk committee on. Confirm the specifics for your business with your own legal and compliance team.

• Credit institutions must comply with Circular 09/2020/TT-NHNN on information system security in banking, which includes requirements on access control, monitoring and access logging.
• Any company that processes personal data must comply with personal data protection rules. Decree 13/2023/ND-CP requires an impact assessment both for processing and for transferring data abroad.
• Some types of business also have to store data in Vietnam under Decree 53/2022/ND-CP, which details the Law on Cybersecurity.

In that setting, three conditions stop being nice to have and become mandatory:

1. Sensitive data is masked before it reaches a model.
2. There's an option to deploy inside the company's own infrastructure, or in-country.
3. The agent's logs are detailed enough to stand as evidence in an inspection or audit.

If a vendor can't meet all three, the pilot shouldn't start. Better to know that in week one than in month three.

Earn trust in 90 days

Controls make it safe to start. They don't make it sensible to hand over everything on day one. Trust needs a clear path, and I recommend three stages over about 90 days.

01Days 1 to 30

Read-only, in parallel

The agent investigates alongside the team. Compare its verdicts with your postmortems.

02Days 31 to 60

Propose, with approval

The agent leads triage and proposes fixes. Every action waits for an engineer.

03Day 61 on

Low-risk by policy

Verified low-risk actions run on their own by policy. Everything else still waits.

Days 1 to 30: read-only, in parallel. The agent only reads. It investigates alongside the team, and you compare its conclusions with your postmortems. Start with the team that has the most repeat incidents, because that's where you'll see the most comparisons fastest. A good way to begin: take incidents whose root causes you already know and check the agent's verdicts against them.

Days 31 to 60: propose, with approval. The agent leads triage and proposes fixes. Every action still waits for an engineer to approve it. You're now measuring two things: how often the proposal was right, and how often the engineer had to change it before approving.

Day 61 on: low-risk actions by policy. Low-risk actions that have proven themselves can run on their own, by policy. Everything else still waits for approval.

Two rules keep this honest. An action moves up only after it has been approved many times without anyone needing to edit it. And it moves back down the moment the agent gets it wrong. That way, trust is built on evidence your own team collected, not on a vendor's promise. Ours included.

Bring the risk committee in first

Bring security and compliance in during week one, not at the end of the pilot. Give them Table 1 as the evaluation framework. Settle the legal requirements on data before anyone grants access. Then run the 90 days.

A pilot designed this way has a very different conversation at the risk committee. The question "can we see it, limit it and stop it?" already has an answer, with logs to show for it.

Once one team is past the pilot, the next risk comes from the speed of growth itself: every team building its own agents, with its own access and its own rules. That's the next part of the series.

Related reading

• After Ten Years of Transformation, the Next Chapter Is Operational Excellence
• Agents on a Unified Layer
• The Agent Never Holds Your Keys
• A Receipt for Every Action
• Auto Mode

Sources

1. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", June 25, 2025.
2. Deloitte, Tech Trends 2026, chapter "Agentic AI Strategy", December 2025.
3. Cloud Security Alliance, The AI Agent Governance Gap, April 2026.
4. Gravitee, State of AI Agent Security 2026 Report, February 2026. (vendor-run survey)
5. WRITER, Enterprise AI Adoption Survey 2026. (vendor-run survey)
6. The 2026 Singapore Consensus on Global AI Safety Research Priorities.
7. State Bank of Vietnam, Circular 09/2020/TT-NHNN on information system security in banking operations.
8. Government of Vietnam, Decree 13/2023/ND-CP on personal data protection.
9. Government of Vietnam, Decree 53/2022/ND-CP detailing certain articles of the Law on Cybersecurity.

Vendor-run surveys are conducted or sponsored by companies that sell solutions in this space. Read them alongside independent sources.