Mapping MCP Server Controls to GLBA Safeguards Rule Access Requirements

What the Safeguards Rule asks of access

The Safeguards Rule, 16 CFR Part 314, requires covered financial institutions to maintain a written information security program with administrative, technical and physical safeguards for customer information. Covered companies must also take steps to ensure that affiliates and service providers safeguard customer information in their care. As of November 2026, the rule applies to financial institutions under FTC jurisdiction that are not subject to another regulator's enforcement authority under GLBA section 505. Bank holding companies and similar institutions follow the Interagency Guidelines, which carry a parallel expectation that access to customer information systems is limited to authorized individuals.

Four elements of 16 CFR 314.4 matter most for MCP. Section 314.4(c)(1) requires implementing and periodically reviewing access controls, and FTC guidance says to determine who has access to customer information and regularly reconsider whether they still have a legitimate business need. Section 314.4(c) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves in writing a reasonably equivalent or more secure control. It also addresses encryption of customer information in transit over external networks and at rest, with Qualified Individual-approved compensating controls where encryption is infeasible. Section 314.4(c)(8) requires controls to monitor and log the activity of authorized users and detect unauthorized access to, use of, or tampering with customer information.

The rule does not mention MCP. The mapping below is analytical: it applies the rule text to the places where an AI agent reaches customer information.

Requirement-to-control crosswalk

The crosswalk reads left to right: the requirement, the MCP control it implies, the enforcement action in the execution path, and the evidence an examiner would reasonably expect. Evidence formats are practitioner inference, since the rule does not prescribe log fields.

• Access controls and periodic review, 314.4(c)(1): Control: a per-agent allow list of servers, tools and data. Enforcement: allow or block before the call executes. Evidence: dated allow-list snapshots and records of each review.
• Legitimate business need: Control: tool and parameter scoping so an agent reaches only the customer information its task needs. Enforcement: redact returned fields, rate limit bulk reads, escalate sensitive actions for human approval. Evidence: the policy applied and the decision for each call.
• Multi-factor authentication, 314.4(c): Control: strong authentication of the human user at the client, and a defined treatment for non-human agent identities. Enforcement: block calls without a valid identity. Evidence: authentication configuration and any written Qualified Individual approval of an equivalent control.
• Encryption in transit and at rest: Control: encrypted connections between client, server and data source, and encrypted data stores. Enforcement: block connections that do not meet policy. Evidence: configuration records and approved compensating controls where encryption is infeasible.
• Monitoring and logging, 314.4(c)(8): Control: a record of each tool call. Enforcement: decision made at call time. Evidence: acting identity, tool, parameters, data returned and policy decision, exportable for review.
• Service provider oversight: Control: an inventory of third-party or hosted MCP servers and the customer information they can reach. Enforcement: allow only approved servers. Evidence: the inventory, approval records and oversight documentation.

Where policy must be enforced in the execution path

Section 314.4(c)(1) calls for technical access controls. In an MCP deployment, a technical control is one that acts before the tool call executes or before data returns to the model. A review that happens afterward can show that an agent retrieved account records it should not have reached, but it cannot prevent the retrieval. Because acquisition of unencrypted customer information is what triggers FTC notification, the difference matters.

Five actions cover most needs. Allow permits a call that matches the agent's approved tools and data. Redact removes fields such as account numbers from a result before the model sees it. Block stops calls to unapproved servers, tools or data. Rate limit constrains bulk reads that could amount to extraction. Escalate for human approval holds high-impact actions, such as writes or exports, until a person decides.

Prompt injection is the reason this cannot rely on the model's own judgment. Instructions hidden in a document or tool result can push an agent toward calls its user never intended. A policy decision made outside the model, against the agent's identity and the specific tool call, holds regardless of what the model was told.

There are tradeoffs. Tight allow lists add administrative work and can slow new use cases. Human approval adds latency, so reserve it for actions where the consequence justifies it. Redaction can reduce answer quality when a task needs the redacted field, which is why scoping should follow the task.

Where Trussed fits

Trussed enforces policy in the execution path across MCP servers and tool calls: allow, redact, block, rate limit and escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence for each interaction and tool call. Trussed offers self-managed deployment in the customer cloud, with configurable retention and data residency.

Trussed does not certify an organization against GLBA or the Safeguards Rule, and it does not provide transaction-level governance or end-to-end tracing of agentic workflows. Its scope is individual interactions and tool calls. Legal interpretation and Qualified Individual decisions remain with your own program.