IETF MCP security draft makes agent access control a KYA baseline
A new MCP security Internet-Draft and fresh enterprise access-control signals point to the same compliance lesson: finance agents need attributable identity, bounded tool authority, runtime policy checks, and logs that survive review.
Daily signal: The June 2026 IETF Internet-Draft on MCP security describes recurring MCP vulnerability classes, including SSRF, excessive tool permissions, prompt-injection exposure, lifecycle bypass, information leakage, and authentication gaps. Noma's June 2 Agent Access Control launch and Okta's agent-identity architecture both frame agent governance around inventory, identity, per-tool authorization, runtime enforcement, and auditability. These are security and market-structure signals, not formal Know Your Agent rules.
Why this matters for KYA
Model Context Protocol gives agents a practical bridge into tools, APIs, data stores, browsers, file systems, and enterprise workflows. In finance, that bridge can touch payment preparation, card controls, customer records, treasury operations, account maintenance, compliance queues, market data, order-routing systems, and exchange APIs.
The IETF draft is useful for KYA because it names the failure modes that turn a tool connector into a compliance exposure. If an MCP server accepts unsafe parameters, follows risky redirects, exposes paths beyond its mandate, answers before initialization, or processes calls without authentication, then the agent's approved role is no longer the same as its effective authority.
Noma and Okta add the operating layer: discover the agent, give it an attributable identity, decide what it can reach at the moment of action, record who authorized the task, and monitor whether runtime behavior still fits the mandate. KYA should convert those controls into an evidence file that compliance, risk, security, and audit teams can read without reverse-engineering the agent stack.
Screenshot-ready KYA compliance comparison table
| KYA dimension | Weak MCP-agent posture | Production-grade KYA posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The agent appears as a shared service account, developer credential, or generic automation client. | Each agent, MCP host, client, server, and tool connection has a stable identity, owner, environment, version, and lifecycle state. | Agent registry entry, accountable owner, issuer, actor chain, deployment version, environment, approval status, revocation record. |
| Agent mandate | The mandate says assist finance, support operations, or investigate issues, while tools can perform broader actions. | The mandate defines allowed tasks, action levels, approval thresholds, stop conditions, and prohibited uses for each tool path. | Mandate class, allowed task list, prohibited action list, approval threshold, expiry, escalation rule, policy version. |
| Wallet and custody | Payment, card, treasury, brokerage, or custody functions are treated as ordinary MCP tools. | Any money movement, signing, account change, or trade path has separate custody limits, simulation, approval, and rollback evidence. | Account perimeter, spend or trade limit, signer role, custody control, transaction preview, approval receipt, cancellation path. |
| Tool and venue access | MCP servers expose broad tools, unsafe URL fetches, filesystem paths, or venue APIs without per-tool risk classification. | Every tool is classified by data class, action type, parameter risk, venue, permission boundary, egress rule, and runtime policy decision. | MCP inventory, tool-risk tier, parameter validation, egress policy, redirect rule, venue access rule, allow or deny decision. |
| Audit trail | Logs show a system action but not the originating human, agent, prompt/task, tool call, policy decision, approval, or denial reason. | The audit chain links human, agent, MCP component, tool invocation, policy version, runtime decision, result, exception, and review outcome. | Run ID, actor chain, task summary, tool call log, policy decision, approval event, denial reason, output filter, audit export. |
| Security and abuse | Controls rely on prompt instructions, broad credentials, default MCP behavior, and after-the-fact manual review. | Least privilege, authentication enforcement, initialization checks, sandboxing, network restrictions, injection testing, monitoring, and kill switches operate at runtime. | Auth check, lifecycle enforcement, sandbox config, SSRF test, prompt-injection test, token rotation, anomaly alert, kill-switch drill. |
| Jurisdiction fit | The same agent workflow runs across countries and regulated activities without local privacy, outsourcing, AML, or resilience mapping. | The KYA file records where the agent may operate, what regulated activity it supports, what data it may touch, and which local controls apply. | Country scope, data residency review, APAC privacy basis, outsourcing assessment, AML mapping, retention rule, incident escalation path. |
The compliance lesson
The IETF draft is explicit that MCP security is still an implementation and operator responsibility. That matters for KYA because formal identity checks on the human or business do not explain what an autonomous agent can do after it receives tool access. The compliance perimeter moves to the connection between identity, mandate, tool boundary, runtime control, and audit trail.
In finance, the most dangerous failure is silent authority expansion. A read-only research agent can become risky if it can fetch internal URLs, traverse files, chain tool outputs into another system, inherit broad credentials, or operate under a service account that hides the accountable human. KYA should force that authority expansion into a visible, testable, and revocable record.
Practical KYA checklist
- Build a live inventory of agents, MCP hosts, clients, servers, tools, owners, versions, environments, and policy states.
- Map every tool to a mandate class: observe, retrieve, analyze, draft, submit, execute, escalate, or stop.
- Require runtime authorization for high-risk calls, including URL fetches, filesystem access, payment paths, trading APIs, customer records, and external sends.
- Preserve the actor chain from the human or business controller through the agent and into the tool or venue.
- Test MCP deployments for SSRF, redirect abuse, DNS rebinding, lifecycle bypass, authentication gaps, prompt injection, excessive permissions, and information leakage.
- Attach APAC privacy, outsourcing, AML, custody, operational-resilience, and record-retention controls to the agent's jurisdiction-fit file.
Bottom line
MCP does not make an agent compliant by itself. It makes the agent's action surface easier to standardize, inventory, test, and audit. KYA is the evidence discipline that turns that surface into a finance-ready record: who controlled the agent, what it was allowed to do, what tool or venue it used, what policy decision applied, and what proof remains after the action.
Sources reviewed: IETF Datatracker Internet-Draft on MCP security considerations; Noma Security Agentic Access Control product page and June 2 launch release; Okta blog on securing agent identity. These are draft, security, and enterprise architecture signals, not claims that any regulator or exchange has adopted a formal Know Your Agent rule.