← Glossary

Devancore Post-Trade Glossary

Agentic AI Controls

Agentic AI controls define what an AI agent may read, propose, stage, execute, escalate, and record inside capital markets workflows.

Definition

Agentic AI controls are the permission, policy, review, monitoring, and evidence controls that govern AI agents in capital markets workflows. The issue is not whether an agent can call a tool. The issue is whether the firm can prove which tool it called, why it was allowed, what records it used, which state it proposed to change, who approved the action, and what the downstream system returned.

Capital markets workflows contain many action types with different risk levels. Reading a position is not the same as drafting an allocation correction. Drafting a settlement instruction is not the same as releasing it. Closing a reconciliation break is not the same as explaining why it exists. A control model that treats all tool calls as one permission class is too blunt for regulated operations.

Agent permission boundary

Agent permission boundary

Every agent capability should map to a permitted action class and evidence requirement.

Capability Allowed role Control evidence
Read Retrieve permitted records, statuses, policies, exceptions, and reports User entitlement, source IDs, timestamps, and fields returned
Explain Summarize facts, gaps, workflow state, and likely next steps Citations, assumptions, confidence, and missing-evidence flags
Draft Prepare notes, payloads, messages, corrections, or tasks without committing state Draft ID, source records, schema result, and reviewer queue
Stage Place a proposed workflow update behind a release gate Policy check, maker-checker status, risk result, and required approver
Release Commit only where policy allows and approval is complete Approver, action payload, idempotency key, downstream response, and timestamp
Stop Pause agent work, revoke tools, escalate, or route human takeover Kill switch event, reason, open state, and recovery owner

The useful design pattern is bounded agency. An agent may retrieve permitted records, classify work, assemble evidence, draft messages, prepare payloads, monitor statuses, and route tasks. Material state changes should pass through deterministic policy checks and accountable review. The boundary should be explicit in the product, the logs, and the supervisory procedure.

Tool scope is the core control. Each agent session should receive a task-specific registry: which records it can read, which fields it can see, which tools it can call, which payloads it can draft, which actions it can stage, and which actions require approval. The registry should reflect the user, role, account, portfolio, business line, environment, and workflow. The boundary should be enforced by the application layer and policy engine, not by prompt instructions alone. A prompt injection, malformed inbound message, or corrupted counterparty file should not be able to persuade the model to discover or request tools outside its approved scope.

Agentic controls also need an intervention path. If a model begins looping, using stale data, calling the wrong tool, producing unsupported citations, or approaching a restricted state change, the system should be able to pause the agent, revoke tools, freeze a workflow item, and route human takeover. The stop event itself becomes part of the operating record.

How it works

Agentic AI controls work by placing a control plane between model reasoning and operating systems. The user defines a goal. The control layer scopes identity and tools. The agent retrieves records, drafts a proposed next step, validates the proposal, routes approval where required, calls the permitted tool, monitors the response, and records the final state.

Agentic workflow controls

Agentic workflow controls

The control plane should constrain reasoning before any tool action changes operating state.

Control layer What it governs Failure mode
Identity User, agent, session, service principal, environment, and business role Unattributed action or shared credential
Tool scope Read, draft, stage, release, export, message, reconcile, or report capability Prompt injection or corrupted input tries to expand the agent's tools
Policy gate Limits, WSP rules, risk thresholds, account eligibility, data freshness, and required evidence Reasonable-looking action bypasses deterministic checks
Human gate Maker-checker, supervisor review, WSP routing, override reason, and approval authority Agent commits a material state change without accountable review
Execution monitor Tool-call status, retries, duplicate suppression, timeout, cancellation, and downstream response Runaway loop, duplicate action, or orphaned task
Audit trail Prompt, retrieved context, tool arguments, validation, approval, supervisory sample state, outcome, and final record state Unreconstructable agent activity

Identity comes first. The record should distinguish the human user, the agent identity, the service credential, the session, the environment, and the business role. Shared credentials weaken accountability because a reviewer cannot tell whether an action came from a user, a model, a scheduled job, or a downstream system.

Tool scope should be dynamic. A user investigating a settlement fail may need read access to trade, SSI, custodian, clearing, cash, and exception records. That same user may not need order release, ledger adjustment, journal posting, or client communication tools in the agent session. Hiding the wrong tools is a control, not a UX preference. The agent should not be allowed to escalate its own authority, even if a user prompt, SWIFT message, ISO message, email, or file payload contains instructions that appear to request it.

Policy gates translate firm rules into machine checks. The workflow should test account eligibility, security restrictions, stale data, missing fields, notional thresholds, settlement risk, WSP routing, maker-checker requirements, and record-retention needs before an action is staged or released. Model confidence should not override those checks.

Human gates apply where judgment, authority, or material state change is involved. A reviewer should see the original prompt, retrieved sources, tool registry, proposed payload, validation result, warnings, and expected downstream effect. Broker-dealer use should be reflected in the firm's written supervisory procedures where the agent participates in supervised activity, so supervisors have a reviewable interface for sampling paths, approvals, holds, overrides, and rejected actions. If a reviewer overrides a warning, the reason should be captured before release.

Execution monitoring protects against agent loops and orphaned work. Tool calls should carry request IDs, idempotency keys where available, retry limits, timeout handling, cancellation state, and downstream response capture. A failed or partial response should create an owned work item, not leave the agent to improvise.

The audit trail is the product of the control plane. It should preserve the question, goal, retrieved context, tool arguments, validation result, draft, approval, release event, downstream response, exception state, and final operating record. Broker-dealer environments may need this evidence to align with FINRA Rule 3110-style supervision, written supervisory procedures, books-and-records policy, and AI governance review.

In Devancore™

Devancore supports agentic AI controls as governed operating-record infrastructure for capital markets workflows. It can help connect user intent, agent identity, tool scope, source records, policy checks, approval states, downstream system responses, exception handling, and audit trail.

Devancore should not be framed as an autonomous trader, broker, custodian, clearing broker, compliance officer, accounting authority, legal adviser, or execution venue. Its role is to help firms govern AI-assisted workflow activity around the systems and people that remain accountable.

In a Devancore-style workflow, the agent starts with a bounded task. The platform scopes tools, retrieves permitted records, validates the proposed action, holds material changes for review, records the human decision, and attaches the downstream response. If the agent hits stale data, missing evidence, an entitlement block, a policy breach, or a retry limit, the workflow moves to a held state with owner, reason, and next action.

This page complements AI agent post-trade operations and MCP trading integration. AI agent post-trade operations describes the tasks agents can assist with. MCP trading integration describes the tool interface. Agentic AI controls defines the governance layer that decides what the agent may do, what it may only propose, and what must be reviewed before operating state changes.

The standard is simple: bounded tools, deterministic gates, human accountability, and reconstructable evidence. If any of those is missing, agentic workflow becomes operational risk instead of controlled operating leverage.