Skip to main content
Autonomy is earned, not configured. Governance is what lets you grant it. This chapter lists the controls to have in place before an agent writes to production: a five-level guardrail stack, the data questions your security team will ask, and the attack surfaces the agent layer adds. Section 6.6 maps each control to where it lives in CloudThinker.

​
6.1 The governance gap

Agentic programs stall when an agent breaks trust with a bad change, or when the risk team blocks deployment for lack of evidence. A written policy, a complete audit trail, and a fast way to stop the agent are what let a risk team say yes.

​
6.2 The guardrail stack

Production guardrails work at five levels. Each level catches a different kind of failure, so you need all five. Two questions decide where an action sits in the policy at level 2: can you undo it, and how much does it touch? A good audit trail has a side benefit: it gives you better change evidence than most human-run processes ever produce.

​
6.3 Data residency and control

Before a regulated security team discusses autonomy, it asks three questions. Agents change the answer to each one.
  1. Residency: where is the data stored and processed? Agents send telemetry to a reasoning model, a data flow classic tooling never had. The inference boundary is now your data boundary. You need to know where each model call runs, what the model provider logs, how long it keeps it, and whether your data trains its models.
  2. Sovereignty: whose law can reach it? Data processed by a foreign-operated service or model API can fall under that country’s disclosure laws, wherever the servers sit. The cautious position for regulated firms is that sovereignty follows the operator, not only the data center.
  3. Control: who holds the kill switch? Control means an audit trail you can export and keep, the ability to revoke every agent credential at once, retention you can enforce, and a clear statement of what crosses your boundary.
The deployment model is the main dial for all three. From least to most control: Two practical notes:
  • The controls stack. The strongest pattern in regulated deployments pairs an isolated deployment with identifier masking in front of every model call. Even in-region inference then never sees a real customer ID, credential, or account number.
  • Control must survive an audit. If a regulator asks for every piece of data the agent sent outside your perimeter in March, your egress logs and audit trail have to answer. Vendor assurances don’t count.
Data rules are tightening in Asia and Europe, including Vietnam’s Personal Data Protection Law, Singapore’s MAS technology-risk guidelines, the EU’s GDPR, and the EU AI Act. Ask your compliance team which ones apply to you, and map each agent data flow (telemetry to the model, model output to your systems) against them.
Eight data-control questions for any agentic vendor
  1. Exactly which data leaves our perimeter, to which endpoints, in which regions?
  2. Can inference run in-region, in a dedicated instance, or fully self-hosted?
  3. Is our data used to train any model, yours or a third party’s, and is that in the contract?
  4. Are personal identifiers and secrets masked before the model boundary, and where?
  5. What do you and your model providers log and keep, and for how long?
  6. Can we run model calls on our own model provider account?
  7. Can we export the complete audit trail if we leave you?
  8. Can we revoke every agent credential and stop all agent writes in one action?
Get the answers in writing before the pilot starts. CloudThinker’s own answers are in section 6.6 below.

​
6.4 Regulated industries

Banks, insurers, and other financial firms have the most to gain from agentic operations: their downtime costs the most and their compliance work is the heaviest. They also have the strictest constraints. Beyond residency and control, three requirements come up in nearly every deployment:
  1. Model risk management. Agents fall under existing model risk frameworks: documented behavior, evaluation suites, periodic revalidation, and challenger processes. Plan for these before the pilot, not after.
  2. Change management fit. Agent actions must map onto your existing change process (pre- and post-change checks, approvals, rollback evidence) instead of going around it. An agent that bypasses the change board gets switched off.
  3. Evidence per action. For every agent write, keep a record of what triggered it, the evidence the agent cited, who approved it, and the outcome, for as long as your change records must be kept. Check that your platform’s retention covers that period, or export the records to your own store.

​
6.5 The agent-layer threat model

Everything above governs what an agent is allowed to do. This section covers what happens when someone attacks the agent itself. An operations agent is a privileged actor that reads telemetry and takes action, which makes it a target. Threat-model it the way you would any new privileged service. Five attack surfaces recur, and each has a mitigation to require before you grant autonomy: Here’s what prompt injection through logs looks like in practice. A log line like this should be read as evidence, never followed:
A well-built agent reports this line as a timeout plus a suspicious string, and the delete never runs because no policy allows it. None of these threats is a reason not to deploy. They’re the reason to deploy with the guardrail stack and audit trail from 6.2. A confidently wrong agent and a maliciously steered agent fail in the same place, and the same controls catch both.
Design principle: build the audit trail first and the autonomy second. A platform that can prove what it did and why, to an engineer, an auditor, or a regulator, will be allowed to do more.

​
6.6 Where these controls live in CloudThinker

If you’re evaluating CloudThinker, this is where to check each control.

​
CloudThinker’s answers to the eight questions

​
A safe first configuration

  1. Set the workspace to Manual before you connect anything. Under Run types, also override Automations to Manual: that row defaults to Auto · Rules + AI · Refuse and doesn’t follow the workspace. A chat can pick its own mode, so check the mode in the composer too. New workspaces start on Auto · Rules + AI · Ask me, where AI judgment can let a write that no Rule covers run by itself if it judges it safe and in scope. Move to that default once your team trusts the agent’s proposals on your systems (see §7.5).
  2. Turn on the Guardrails identifiers that match the data in your logs.
  3. Accept an Allow Rule only for a write that has cleared the graduation bar in §8.2. Allow Rules run writes alone only under Auto, and only once CloudThinker turns on Rule enforcement for your workspace; until then the Approval mode alone decides. In Manual, a person still approves them.
Approvals walks through the setup step by step. Next: Chapter 7 · Humans on the Loop covers how roles change once these controls are in place, and how to raise autonomy one step at a time.