Authorization in Model Context Protocol (MCP) is optional, and NSA’s first security assessment of the protocol, its Cybersecurity Information Sheet on MCP published in May 2026, reiterates it. Read one way, it means the protocol leaves security up to whoever builds on it, trading a mandated model for vendor flexibility and control. Read another way, it means the one control that matters most for production data access was never made part of the protocol specification in the first place, which is exactly why it’s easy to skip when a deployment moves fast.
This guide covers what field-level security means in an MCP architecture, why access models built for human users break down when the requester is an agent, and how passthrough identity, scoped tools, and audit logging make least-privilege provable rather than assumed.
What it means to secure an AI agent at the data layer
Securing an AI agent means controlling what it can reach at the data layer, before any data or context reaches the agent. The OWASP AI Agent Security Cheat Sheet describes agents as autonomous systems that reason, plan, use tools, and take actions, which introduces risk categories beyond the prompt injection concerns that dominate LLM security discussions.
Quick definition: data-layer security
Enforcing access controls at the point where an agent queries a source system, so restrictions are evaluated against the data itself, not assumed from the agent’s prompt or wrapper.
The data layer is the right enforcement point because agents leak through channels below the prompt. OWASP notes that agents can expose sensitive information through tool calls, API requests, and their own outputs. A guardrail written into a system prompt won’t stop a tool call from returning a salary column.
Query-time enforcement changes the question. Instead of asking whether the agent behaved correctly, permissions are inherited from the source, so the agent sees what the requesting user would see on a direct login. Our analysis of MCP security risks covers the implementation flaws behind these gaps.
Why traditional access control models break down in agentic contexts
Traditional access control grants broad access once a user authenticates, and that assumption collapses when the requester is an agent. NIST SP 800-207, the federal standard for Zero Trust Architecture, describes the perimeter model as one built on implicit trust, where anything inside the network boundary is treated as authorized. An agent chains operations across trust boundaries in one request, so implicit trust becomes implicit privilege.
And MCP itself doesn’t close the gap, as the NSA assessment described above notes. Servers rely on OAuth 2.1 bearer tokens without lifecycle management for refresh, revocation, or reuse control, and MCP lacks support for exchanging role-based access control permissions at instantiation.
Alongside that gap, two failure patterns follow:
Shared service accounts. One broad credential covers every user, so no query can be attributed to the human who triggered it, and least-privilege has nothing to attach to.
The confused deputy problem. Described in the MCP authorization security considerations, it lets attackers exploit MCP servers acting as intermediaries to third-party APIs and obtain access tokens without user consent.
Access control assumption | Why it holds for human users | Why it breaks for AI agents |
An authenticated session implies an authorized user | The session is bound to one logged-in person | The request is non-human and may carry an injected instruction or a reused token |
Coarse system-level access is acceptable | People self-limit to their job function | An agent queries whatever the connection exposes |
One credential per integration is manageable | Integrations are few and long-lived | Every agent, platform, and workflow multiplies credential count |
Logs capture who did what | Actions map to a named identity | A shared account attributes everything to one generic user |
For all these failure patterns, our best practices for secure AI agent governance work through the controls in sequence.
What field-level security means in an MCP architecture
Quick definition: field-level security
Access control scoped to a specific field within a source system, whether that's a column, a row, or a table, instead of all-or-nothing access to a whole connection or tool.
Coarse tool-level permissions have already proven insufficient. The NSA sheet documents the GitHub MCP server case, where blanket user consent gave tools unrestricted read and write access across private and public repositories. That missing granular authorization let compromised tools read private content and publish it publicly without the user’s awareness.
The protocol is moving toward finer control. Guidance from the Coalition for Secure AI recommends reducing scopes for least privilege, such as removing write scopes when read access is enough, and notes that SEP-835, the proposal that added native scope definitions to MCP, did so in the 2025-11-25 specification. The current 2026-07-28 revision carries that forward, requiring clients to send the RFC 8707 resource parameter so tokens bind to the resource they were issued for.
Scoping below the server level separates a governed deployment from a connected one. Access should resolve to individual tools, parameters, and operations, which requires knowing the shape of the data before the first query runs. Auto-discovered data models that expose tables, fields, and relationships make column-level restrictions definable in advance. If you can’t name the columns an agent can read, you can’t restrict them.
How OAuth/SAML passthrough eliminates credential sprawl
The term passthrough gets used for two different mechanisms:
Identity passthrough. An agent’s query inherits the requesting user’s existing entitlements from the source system through OAuth or SAML.
Token passthrough. An MCP server forwards a raw bearer token downstream. The current specification forbids it.
The prohibition is explicit. The MCP authorization spec states that servers MUST validate that tokens presented to them were issued specifically for their use, and MUST NOT pass through the token received from the MCP client. Where a server calls an upstream API, it acts as an OAuth client to that service and obtains a separate token. Forwarding the original creates confused deputy conditions.
Identity passthrough operates at a different layer. MCP servers act as OAuth 2.1 resource servers, with a separate authorization server issuing tokens, and the identity resolved through that flow determines what the query returns.
CData Connect AI applies the requesting identity at query time, and the source system enforces its own permissions exactly as it would for a direct login, including row-level security, field-level access, and role-based controls. That means no shared service account and no parallel permission model to audit, since the agent’s query inherits entitlements the user already has.
Model | How the agent authenticates to data | Audit attribution | Credential sprawl risk |
Shared service account | One broad credential for all users | None, since queries aren’t tied to a person | High |
Static API key or PAT per integration | Long-lived secret stored per connection | Partial, at connection level only | High |
Raw token passthrough | Client token forwarded downstream | Broken, and forbidden by the specification | High |
Identity passthrough via OAuth or SAML | End user’s own credentials at query time | Full, per user and per query | Low |
The API layer underneath has its own attack surface, covered in our guide to agent-based API security.
Enforcing least-privilege with workspace isolation and scoped tools
Least-privilege, the security practice of granting only the minimum access a task requires, starts with the tool inventory for agents. OWASP recommends granting agents the minimum tools required, scoping permissions per tool such as read-only versus write, and requiring explicit authorization for sensitive operations. It also advises separate tool sets for different trust levels, which makes purpose-built scoping enforceable across Copilot Studio, n8n, and LangChain.
Quick definition: workspace isolation
Partitioning agents so each reaches only the systems and data authorized for its purpose. A finance agent sees finance data, a sales agent sees CRM data, and neither crosses into the other.
NIST’s zero trust guidance (SP 800-207) adds that least-privilege restricts visibility as well as accessibility, and authorizes access only for the duration of a task or session. Visibility matters here, because a tool an agent can enumerate is one it can attempt to call.
Adoption lags the guidance. Astrix Security’s State of MCP Server Security 2025 analyzed more than 5,200 public repositories and found that 88% of MCP servers require credentials, 53% rely on long-lived static API keys or personal access tokens, and only 8.5% use OAuth. Least-privilege is hard to claim when the credential never expires.
Connect AI’s least-privilege model splits this into two distinct boundaries. Workspaces define the data boundary by specifying which datasets, schemas, or views are accessible, and Toolkits define the action boundary by determining which Universal, Source, or Custom Tools are available. That gives you visibility control as well as access control right at the platform layer, before an agent ever sees a tool or a table. Each combination can be deployed as a dedicated MCP server, so an agent operates only within its intended scope.
Audit trails that map to SOC 2, ISO 27001, and GDPR requirements
An ideal log has enough detail that the trail is granular and lineage can be traced back to the human who triggered it: user identity, the query itself, the systems accessed, the data returned, and a timestamp for every action.
That ideally can be broadly grouped into three frameworks:
ISO/IEC 27001:2022. Annex A 8.15 Logging, 8.16 Monitoring activities, and 8.17 Clock synchronization form a connected control set, with 8.15 requiring that logs be produced, stored, protected, and analyzed.
SOC 2 CC7.2. Requires continuous monitoring to detect anomalies, and auditors expect both successful and failed access attempts in scope.
GDPR Article 5(1)(c). Requires that personal data be adequate, relevant, and limited to what is necessary, which is what field-level restriction operationalizes.
Logs also have to leave the platform, since export to a security information and event management (SIEM) system is what turns a log store into compliance evidence.
Requirement | Standard or control | How field-level MCP logging satisfies it |
Restrict access to necessary data only | GDPR Article 5(1)(c) data minimisation | Query-time field restrictions limit returned columns to what the user’s role permits |
Produce and protect activity records | ISO 27001 Annex A 8.15 | Every query logged with user, statement, and result metadata, protected against tampering |
Detect anomalous access continuously | SOC 2 CC7.2 | Per-query attribution surfaces out-of-pattern agent behavior for monitoring |
Attribute every action to an identity | ISO 27001 Annex A 8.16 | Passthrough identity binds each request to a named user rather than a service account |
Connect AI enforces per-user authentication with native source-system permissions applied at runtime, backed by full audit trails and independently audited against SOC 2 Type II, ISO 27001, and GDPR. For the wider control set IT owns, see our guide to AI agent data governance.
Ungoverned vs. governed MCP in a before-and-after comparison
The difference between a governed MCP deployment and an ungoverned one is whether authorization is decided per request or assumed at connection.
Dimension | Ungoverned MCP (before) | Governed MCP with field-level passthrough (after) |
Identity | Shared token or service account, no per-user attribution | Each query inherits the requesting user’s OAuth or SAML identity |
Scope | Full tool surface exposed on authentication | Scopes resolved per tool, parameter, and operation |
Data boundary | Whatever the connection can reach | Specific datasets, schemas, and columns |
Credentials | Long-lived keys and stored tokens persist as attack surface | Short-lived, scoped credentials validated at runtime |
Audit | Minimal metadata, often absent | Query-level records tied to a named identity |
Failure mode | Confused deputy, replay, silent scope creep | Rejected token, denied scope, logged attempt |
These failure modes are documented rather than theoretical. The NSA sheet catalogues poor approval workflows where a trusted server’s capabilities change without user consent, and missing audit logs that make incident response impractical. A study of 1,899 open-source MCP servers found 7.2% contained general vulnerabilities and 5.5% exhibited MCP-specific tool poisoning.
The governed pattern is a short list of enforcement points. Bind every session to a user identity rather than a connection, validate token audience on every request, and log each action with the triggering identity. Without a governed layer, MCP defaults to shared credentials and broad scopes. With one, every agent query is bound to a user identity and validated per request.
Build a defensible, field-level security architecture for your AI agents
A solid, defensible field-level security architecture for MCP AI agents comes down to a few verifiable properties:
Identity integration. Integrate with the identity provider you already run, rather than standing up parallel user management.
Granular scoping. Scope access below the server level, to individual tools and parameters.
Token validation. Reject any token not explicitly issued for your server.
Session lifetime. Bind tokens and sessions to short, defined lifespans, so a compromised credential expires quickly instead of lingering as standing access.
Per-request evaluation. Evaluate authorization per request against the source system’s permissions, rather than inferring it from the prompt. That last point is zero trust applied to a non-human requester.
The goal is to say yes without creating security debt, and one governed MCP interface where permissions are inherited at query time gets you there, because the model you approve is the one your source systems already enforce.
Frequently asked questions
What does it mean to secure AI agents, and why is it different from traditional application security?
Securing an AI agent means controlling which systems, tables, and columns it reaches at query time. Traditional security assumes a human who authenticates once and self-limits to their role. An agent chains tool calls across systems in one request, so authorization has to be evaluated per request.
What is field-level security in the context of MCP, and why does it matter for enterprise AI deployments?
Field-level security restricts an agent to specific tables, columns, and rows rather than a whole connection or tool. Tool-level permissions are too coarse. The NSA documented MCP tools receiving unrestricted repository access after connection-level consent.
How does MCP passthrough security prevent AI agents from accessing more data than a user is authorized to see?
The end user’s own credentials reach the source at query time, and the source enforces its existing row-level, field-level, and role-based controls. The agent has no independent entitlements to exceed. Token passthrough is a different mechanism, and the specification forbids it.
What is least-privilege access, and how do you apply it when securing AI agents connected to enterprise systems?
Least-privilege grants only the access a task requires, for only as long as it requires it. For agents, limit the tool inventory, scope permissions per tool rather than per session, and require explicit authorization for writes.
How do audit trails and logging work for AI agents using MCP, and what do compliance teams need to see?
Compliance teams need user identity, query text, systems accessed, data returned, and timestamp for every action. That maps to ISO 27001 Annex A 8.15 and 8.16, SOC 2 CC7.2, and GDPR Article 5(1)(c).
How does workspace isolation in MCP help enforce field-level security across different business units or agent use cases?
Workspace isolation partitions agents so each reaches only its authorized systems and data. In Connect AI, Workspaces define the data boundary and Toolkits define the action boundary. Each combination can run as a dedicated MCP server, so a finance agent and a sales agent share a platform without sharing scope.
Get field-level granularity with CData Connect AI
CData Connect AI applies the architecture this guide describes. Passthrough identity binds every agent query to the user’s own OAuth or SAML credentials, Workspaces and Toolkits scope data and actions independently, and every query logs with full attribution, backed by SOC 2 Type II, ISO 27001, and GDPR audits.
That identity and audit model holds wherever your agents run, including Claude, Databricks Agent Bricks, and Microsoft Copilot Studio.
Start a free trial of CData Connect AI to give your agents governed, field-level security access to live enterprise data.
Your enterprise data, finally AI-ready.
Connect AI gives your AI assistants and agents live, governed access to hundreds of enterprise systems — so they can reason over your actual business data, not just what they were trained on.
