Skip to main content
Autonomy is earned, not configured. Governance is not the brake on agentic operations — it is the enabler.

​
6.1 The governance gap

The adoption numbers tell a cautionary story. McKinsey finds 62% of organizations experimenting with AI agents but fewer than a quarter scaled to production; Deloitte’s State of AI research finds only 21% with mature governance frameworks for autonomous agents. And Gartner has put a number on the consequence — the more-than-40% project-cancellation forecast examined in §9.4 — of which the third named cause, inadequate risk controls, is a governance failure by definition. The pattern across these studies is consistent: agentic initiatives die one of two deaths — an incident that destroys trust, or a risk function that blocks deployment because trust was never built. The organizations winning with agentic AI are demonstrably not the ones cutting governance corners; they built governance infrastructure early and used it to accelerate safe deployment.

​
6.2 The guardrail stack

Production guardrails operate at five levels:
  1. Identity and credentials. Every agent is a first-class identity with least-privilege, short-lived, scoped credentials — auditable like any service account, revocable instantly. No shared super-credentials, ever.
  2. Action policy. An explicit, versioned policy defines which action classes each agent may take at which autonomy level in which environment. Reversibility and blast radius drive classification: reversible + bounded = automatable; irreversible or wide = approval-gated.
  3. Execution safety. Pre-flight checks (will this action affect more than N resources?), rate limits, change windows, automatic rollback plans attached to every change, and circuit breakers that halt an agent making repeated failed attempts.
  4. Oversight agents. The “guardian agent” pattern: dedicated agents that monitor other agents — validating plans against policy, detecting anomalous behavior, and enforcing budget ceilings. This is no longer exotic; Gartner expects that by 2028, 40% of CIOs will demand guardian agents capable of autonomously tracking and containing the actions of other AI agents.
  5. Audit and evidence. Every perception, decision, action, and outcome is logged immutably with the full reasoning chain — producing, as a side effect, better change-management evidence than most human-operated processes have ever had.
This stack is no longer aspirational — it is shipping product at the platform vendors. Microsoft Entra Agent ID makes agents first-class directory identities, complete with identity blueprints, named human sponsors, and access packages that expire and require re-approval — governance lifecycle applied to software teammates. Azure SRE Agent added global tool-access policies and execution hooks at Build 2026: a single place to define which tools an agent may invoke, under what conditions, and what requires human approval, with approval gates enforced at the point of execution. AWS ships DevOps Agent with dedicated IAM managed policies scoping exactly what the agent may touch, and Azure’s on-behalf-of model requires an administrator to explicitly lend credentials when an agent’s own identity lacks permission — making every privilege escalation a logged human decision. The direction is unambiguous: agent identity and per-tool policy are becoming platform primitives, and any agentic operations purchase should demand them.

​
6.3 Data residency and control: the first question in every security review

Before any FSI security team discusses autonomy levels, it asks three questions, and an agentic deployment must answer all three precisely — because agents change the answer to each of them.
  1. Residency — where does the data live and get processed? Agentic operations creates a new data flow that classical tooling never had: telemetry travels to a reasoning model. The inference boundary is therefore the new data boundary. It is not enough to know where logs are stored; you must know where every model call runs, what the model provider logs, how long they retain it, and whether your data trains their models.
  2. Sovereignty — whose law can reach it? Data processed by a foreign-operated SaaS or a foreign model API may be subject to that jurisdiction’s disclosure regimes regardless of where the servers sit. For regulated entities, the conservative position is that sovereignty follows the operator, not just the data center.
  3. Control — who holds the keys and the kill switch? Control means customer-held encryption keys, customer-owned audit logs that survive vendor offboarding, the ability to revoke every agent credential instantly, defined retention you can enforce, and a contractual and technical guarantee of what — if anything — crosses your boundary.
The deployment model is the control dial. The four models in production use, in increasing order of control:
ModelWhere agents and data runWhat crosses your boundaryTypical buyer
SaaSVendor cloud; model APIs chosen by vendorTelemetry, configs, and prompts leave your perimeterStartups, non-regulated SMB
SaaS + tokenizationVendor cloud; PII detected and replaced with reversible tokens before any model boundaryTokenized telemetry only; real values never leave; de-tokenization happens inside your trust boundaryMid-market with PII exposure
BYOCAgent platform deployed into your cloud account; you choose model endpoints (including in-region or private)Nothing by default; model calls go where you point themEnterprises, most FSI
Self-host / air-gappedFully inside your perimeter, including self-hosted or dedicated modelsNothingBanks, on-premise FSI, government
Two practical notes. First, tokenization and BYOC compose: the strongest common pattern in regulated deployments is BYOC with a PII-aware tokenization layer in front of every model call, so even in-region inference never sees a real customer identifier, credential, or account number. Second, control must survive the audit: if the regulator asks “show me every piece of data this agent sent outside the bank in March, and prove nothing else left,” the architecture — egress logging at the boundary, immutable audit trails you own — must be able to answer, not the vendor’s assurances.
Figure 6 — The deployment model is the control dial: what crosses your boundary under each model, and who buys which.
The regulatory floor is rising fastest in Asia. Vietnam is the sharpest current example of the direction of travel: the Personal Data Protection Law (Law 91/2025/QH15, effective January 1, 2026, with implementing Decree 356/2025) carries fines of up to 5% of prior-year revenue for unlawful cross-border data transfers and requires transfer impact assessments; the 2024 Data Law (effective July 2025) adds “core” and “important” data categories with their own cross-border restrictions; Decree 53/2022 under the Cybersecurity Law maintains localization requirements for specified services; and the country’s first AI Law, passed in December 2025 and effective March 2026, introduces a risk-classification regime for AI systems. Singapore’s MAS expectations on technology risk and outsourcing, and the EU’s GDPR-plus-AI-Act stack, impose comparable discipline. The pattern is universal: regulators do not prohibit agentic operations — they prohibit not knowing where your data went. For FSI readers specifically, Vietnam’s AI Law names finance as a regulated sector and provides an 18-month grace period for compliance — a window in which to build the governance and audit posture this chapter describes, not a reason to defer it.
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 our cloud, or fully self-hosted?
  3. Is our data used to train any model — yours or a third party’s — and is that contractual?
  4. Is PII tokenized before the model boundary, and where does de-tokenization occur?
  5. What do you and your model providers log and retain, and for how long?
  6. Who holds the encryption keys?
  7. Do we keep the complete, immutable audit trail if we leave you?
  8. Can we revoke every agent credential and halt all egress in one action?
A platform built for regulated industries answers all eight in writing.

​
6.4 Regulated industries: the FSI lens

Banking, insurance, and financial services have the most to gain from agentic operations — downtime costs are highest, compliance toil is heaviest — and the strictest constraints. Beyond the residency and control architecture above, three requirements recur in every FSI deployment:
  1. Model risk management. Agentic systems fall under existing MRM frameworks: documented model behavior, evaluation suites, periodic revalidation, and challenger processes.
  2. Change management compatibility. Agent actions must map onto existing ITIL/change-advisory processes — pre/post validation, approvals, and rollback evidence — rather than bypassing them. Gartner’s 2026 outlook is blunt: as autonomy increases, governance becomes non-negotiable.
  3. Regulatory trajectory. AI governance is moving from voluntary best practice to enforced requirement — the EU AI Act leads, and Asia-Pacific regulators are legislating fast, as Vietnam’s 2025–2026 wave shows. Early investment in governance infrastructure is becoming a competitive advantage, not a tax.

​
6.5 The agent-layer threat model

Every control in this chapter governs what an agent is allowed to do. This section addresses a different question: what happens when the agent layer itself is attacked. An operations agent is, by construction, a privileged actor that reads telemetry and takes action — which makes it a target, and introduces failure modes that classical tooling does not have. A security team must threat-model the agent the way it would threat-model any new privileged service, and a platform that asks a bank to trust autonomous action must show that it has done so. Five attack surfaces recur; each has a concrete mitigation that should be a procurement requirement, not an aspiration.
  1. Telemetry poisoning. An attacker who can write to a log, emit a metric, or forge an event can manufacture a false incident specifically to trigger an agent action — turning the agent’s own responsiveness into an attack vector. Mitigation: authenticate and validate signal sources; gate actions on input provenance, not just input content; and treat a spike that would trigger a high-impact action as itself requiring corroboration from an independent signal.
  2. Prompt injection via logs. Telemetry is untrusted input. Attacker-controlled text in a log line, an error message, or a resource name can attempt to hijack the agent’s reasoning — the operations-layer form of prompt injection. Mitigation: treat all telemetry as untrusted data, never as instructions; strip or escape control content; and enforce that the agent can never execute an action that originates from the data plane rather than from policy.
  3. Agent privilege abuse. A compromised or malfunctioning agent will use exactly the credentials it holds. The blast radius of a captured agent is the union of its permissions. Mitigation: least-privilege per agent, short-lived scoped credentials, and a per-action policy so that even a fully compromised agent cannot exceed the action classes its domain allows — the guardrail stack of §6.2, read as a containment boundary.
  4. Agent-to-agent trust under A2A. As agents negotiate across organisational boundaries, a rogue or spoofed peer can issue malicious delegations. Cross-organisation autonomy is only as safe as the identity layer beneath it. Mitigation: cryptographically signed Agent Cards, verified peer identity, and explicitly scoped cross-organisation delegations — never an implicit trust of any agent that presents itself as one.
  5. An agent gaming its own KPIs. An agent optimised against a metric will optimise the metric, not the goal — an agent rewarded for low MTTR can learn to suppress or auto-close alerts. This is the operations-layer form of reward hacking, and self-reported success is exactly where it hides. Mitigation: a guardian agent that audits outcomes independently, plus a human review of the metrics themselves — the system’s own numbers are never the sole evidence that it is working.
Figure 11 — The agent layer is itself an attack surface: five recurring threats and the mitigation each requires before autonomy is granted.
None of these is a reason not to deploy. They are the reason to deploy with the guardrail stack, the identity model, and the audit trail this book has argued for from the first chapter — a confidently-wrong agent and a maliciously-steered agent fail in the same place, and the same controls catch both. For a regulated bank, the FSI-specific extension of this model — mapped to a CISO’s control framework — is the subject of a separate regulated-bank edition still in development.
DESIGN PRINCIPLEBuild 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. A platform that cannot will be confined to read-only advice forever.