Why exchange AI agents need runtime governance
Cryptocurrency exchanges are adopting AI assistants and agents for customer operations, fraud and risk workflows, market surveillance, compliance casework, and stablecoin-related processes. These agents typically combine a model, an orchestration layer, retrieval over internal knowledge, and connectors to trading, KYC/AML, case management, wallet or operations, and market data systems.
The governance risk is concentrated at runtime. When an agent can read sensitive data or invoke privileged tools, failures are not limited to poor answers. OWASP’s Top 10 for LLM applications highlights excessive agency, sensitive information disclosure, insecure output handling, and insufficient logging and monitoring. Those risks map directly to unintended tool sequences, data exfiltration via retrieval, privilege escalation through over-broad API access, and investigative blind spots.
Authoritative AI risk guidance reinforces the same control themes. NIST’s AI RMF and Generative AI Profile stress roles, policies, privacy and security, human-AI configuration, and ongoing monitoring when systems interact with enterprise tools. ISO/IEC 42001 frames policy, risk assessment, and operational controls inside an AI management system. For virtual asset service providers, FATF-aligned AML/CFT expectations for customer due diligence, record-keeping, and suspicious transaction reporting still apply when AI assists or initiates steps in those workflows. Runtime AI governance is how exchanges make those obligations enforceable on agent actions, not only on human operators.
Highest-governance-risk exchange workflows
Not every agent use case carries equal consequence. Inventory workflows by impact on customer assets, market integrity, AML/CFT obligations, custody-adjacent operations, and stablecoin processes before enabling write or admin tools.
Customer operations and support agents that can retrieve KYC packages, account history, or internal case notes create privacy and insider-risk exposure even when they cannot move funds. Fraud and risk agents that open or close cases, adjust limits, or trigger freezes affect customer access and loss containment. Market surveillance agents that dispose alerts or escalate cases influence market integrity and regulatory examinations. Compliance agents that draft or file-related actions still depend on complete, attributable records.
The highest-consequence surfaces are tools that change state in order or account systems, privilege-sensitive admin APIs, treasury interfaces, and stablecoin operational controls such as mint, redeem, or related ops workflows. Any agent path that can chain read tools into write tools increases the chance of confused-deputy abuse or prompt-injection-driven tool misuse. Classify tools into tiers such as read, write, and fund movement or account change, and treat higher tiers as deny-by-default until policy, approval, and evidence requirements are proven in pre-production.
| Tier | Example surfaces | Default posture |
|---|---|---|
| Read | Market data, knowledge retrieval, case notes (scoped) | Allow with least privilege and logging |
| Write | Case open/close, limit adjustments, alert disposition | Policy allowlist; human review as required |
| Fund / account change | Freezes, transfers, treasury, stablecoin mint/redeem ops | Deny-by-default; approval and dual control |
Runtime enforcement architecture
Runtime governance differs from static application safeguards. Filtering, grounding, and prompt instructions reduce some model failures, but they do not authorize a specific tool call against identity, session context, data classification, and tool-specific rules at execution time. Place a policy enforcement point in the agent tool-call path so every external action is evaluated before it runs.
Separate agent identity from human user identity. Issue short-lived credentials and scoped tokens bound to workload identity and, where relevant, to the human initiator and session. Avoid shared long-lived API keys embedded in orchestrators. Apply least privilege with explicit allowlists of tools, parameters, environments, and rate limits. Network isolation and secrets management should align with the same boundary: the agent runtime receives only the credentials needed for the approved call.
High-impact actions should leave the autonomous path. Freezes, large transfers, surveillance dispositions, account changes, and stablecoin mint or redeem operational interfaces belong behind human-in-the-loop approval workflows, with dual control where existing operations already require it. Emit immutable, time-synchronized audit events to a tamper-resistant store that security, risk, and compliance teams can query independently of the agent process. Evidence should capture who or what agent acted, on whose behalf, which policy version applied, inputs or redacted equivalents, tool parameters, the approval chain, and the outcome.
Implementation sequence for governance leaders
Treat AI agent governance as an extension of existing control planes, not a parallel unverifiable stack. The following sequence keeps policy design, enforcement, and evidence collection aligned with exchange operations.
-
Inventory agents and tool impact
Catalog agents by workflow, data classes touched, and tool tiers (read, write, fund or account change) before enabling privileged connectors.
-
Place enforcement in the tool-call path
Evaluate every external action against identity, session context, parameter rules, and impact tier before execution.
-
Bind identity and least privilege
Issue short-lived, workload-bound credentials; avoid shared long-lived keys; scope tools, environments, and rate limits explicitly.
-
Route high-impact actions to approval
Require human-in-the-loop and dual control where operations already demand it for freezes, transfers, surveillance, and stablecoin ops.
-
Export independent audit evidence
Send immutable, policy-versioned records into SIEM, GRC, and examination workflows outside the agent process.
Map agent controls to existing risk and compliance processes
AI should not become a standalone control silo. Map agent actions and policy evidence into operational risk, information security, model risk where applicable, compliance testing, and internal audit programs already used by the exchange.
NIST SP 800-53 families such as access control, identification and authentication, and audit and accountability provide a familiar catalog for expressing runtime requirements. Cloud security guidance for generative AI and agents similarly stresses workload identity, least-privilege access to tools and data, network isolation, tool-use guardrails, and comprehensive logging. The EU AI Act’s risk-based framing, where applicable, adds expectations around transparency, human oversight, and logging for higher-risk uses. None of these replace VASP-specific AML/CFT, record-keeping, or market integrity obligations; they constrain how AI may participate in meeting them.
Assign ownership clearly. Technology owns agent runtime integration and kill-switch execution. Security owns identity patterns, monitoring, and incident forensics. Compliance owns record completeness for regulated workflows. Business operations own approval matrices and exception paths for trading, customer, and stablecoin processes. Document exception management, policy change control, and post-incident review so governance remains operational under pressure.
Operating practices that keep controls durable
Implementation fails when policy is written once and never exercised under change. Keep the control system continuous: retest allowlists when tools or models change, exercise approval paths under realistic load, review audit completeness with compliance and internal audit, and treat prompt-injection and confused-deputy scenarios as standard pre-production tests for multi-tool agents.