Security teams approving agent access to production systems keep asking two questions: whose permissions does the agent use, and what record exists afterward? Identity passthrough and request-level audit logs answer both.
Why AI agents need different access controls than human users
Agents act autonomously, run continuously, and chain tool calls across systems, so agents exercise permissions at machine speed, without the judgment a person applies. Security teams that block agent rollouts cite three failure modes: credentials exposed through shared service accounts, audit gaps, and scope creep. The Open Worldwide Application Security Project (OWASP) Top 10 for Agentic Applications tracks scope creep as ASI03, Identity and Privilege Abuse, where leaked credentials let agents operate far beyond their intended scope.
Least privilege means granting a user, or a process acting on that user's behalf, only the access needed to complete its assigned task and nothing more. The National Institute of Standards and Technology (NIST) Special Publication 800-53, control AC-6 applies the principle explicitly to processes acting on behalf of users, a control that governance teams already audit against. Agent access control should extend the identity and role-based access control (RBAC) already present across an organization's systems. A parallel permission model duplicates those rules and drifts, so enforcement belongs outside the agent itself.
Identity passthrough vs. shared service accounts
A shared service account routes every agent request through one over-privileged credential, which erases who asked for what and gives every user the account's full reach. The resulting exposure is the confused deputy problem, a security flaw where an attacker tricks a trusted intermediary with broad privileges into using those privileges for a requester who should not have them.
The official security best practices for the Model Context Protocol (MCP) name the confused deputy as a core attack class and list mitigations such as per-client consent and exact redirect URI validation. Identity passthrough, typically through OAuth or Security Assertion Markup Language (SAML), propagates the user's identity so the source system enforces that user's own permissions. The MCP spec forbids token passthrough, where an MCP server forwards a client's token downstream, and requires servers to validate that tokens were issued specifically for them. CData Connect AI applies the same model: each request runs under the requesting user's existing source permissions, with no shared service account.
Approach | Whose permissions apply | Audit attribution | Primary risk |
Shared service account | Service account's (often admin) | Generic account only, no named user | Confused deputy and credential sprawl |
Identity passthrough (OAuth/SAML) | Requesting user's own | Named user on every request | Depends on accurate source-system roles |
Per-agent static API key | Key's fixed scope | Agent only, no named user | Long-lived secret that leaks and rarely rotates |
How MCP agent authentication works: OAuth 2.1, PKCE, and SSO
The MCP authorization spec defines three roles. The MCP server acts as an OAuth 2.1 resource server, the MCP client acts as an OAuth 2.1 client on behalf of a resource owner, and a separate authorization server issues tokens. Authorization is formally optional and applies to HTTP-based transports.
The flow has five steps:
The client calls the MCP server and receives a 401 response with protected resource metadata.
The client discovers the authorization server.
The client requests an authorization code with a Proof Key for Code Exchange (PKCE)
The client exchanges the code for an access token.
The client calls the MCP server with the scoped token.
PKCE, defined in RFC 7636, defends against authorization code interception. MCP clients must use the S256 challenge method when technically capable. They must also include the RFC 8707 resource parameter so tokens bind to a specific MCP server.
Single sign-on (SSO) fits at the authorization server. When the enterprise identity provider (IdP), such as Okta or Entra ID, handles login, the agent's token reflects the real user's identity and groups. Connect AI supports OAuth and SAML passthrough, so that identity reaches each connected source system (agent authorization walkthrough). Per-user SSO passthrough is available on the Business plan, and the Growth plan includes passthrough at the workspace level.
Enforcing least privilege for MCP agents
Least privilege for agents starts with deny-by-default: allow only required sources, tools, and actions. NIST AC-6 expects processes to run at privilege levels no higher than necessary. OWASP's guidance on tool misuse (ASI02) shows why tool scope matters even when the agent's identity is legitimate. The enterprise MCP security playbook adds a step-by-step companion.
Blocking write actions
Create, read, update, and delete (CRUD) scoping removes write risk for reporting and analysis agents, since the agent can fetch data but cannot act on records. Connect AI can block write actions at the connection level even when the user holds write rights, per the MCP guidance on minimal scopes. Field-level security in MCP extends the restriction to individual fields.
Separate workspaces for each team's agents
Workspace isolation acts as a trust boundary. A finance workspace exposes only finance sources, so a misled finance agent has no connection to HR or CRM data. One workspace per team or trust level fits better than one per company, as multi-agent deployments show.
Agent type | Allowed operations | Workspace scope | Approval needed |
Sales reporting agent | Read only (write actions blocked) | Sales workspace: CRM and billing views | None |
Finance reconciliation agent | Read, plus updates to flagged ledger records | Finance workspace: ERP and general ledger | Human approval before each update |
What an MCP agent audit trail should capture for SOC 2, GDPR, and CCPA
Log field | Example value | Why auditors need it |
Named user identity | [email protected] (via SSO) | Attributes every agent action to an accountable person |
Agent or client identity | finance-agent | Separates agent from user |
Request or tool call text | Fetch invoices overdue by 30 days | Shows exactly what the agent asked for |
Systems and objects accessed | NetSuite: Invoice, Customer | Proves scope stayed inside the approved boundary |
Timestamp | 2026-11-06T14:32:08Z | Orders events |
For SOC 2, the fields support Common Criteria CC6, Logical and Physical Access Controls, part of Security, the only Trust Services Criteria category required in every SOC 2 report. For the General Data Protection Regulation (GDPR), Article 30 requires controllers to keep records of processing activities, and those records support the Article 5(2) accountability principle. Per-request agent logs serve as supporting evidence, since Article 30 itself does not mandate them. For the California Consumer Privacy Act (CCPA), consumers can ask what personal information a business collects, uses, and shares, as the California Attorney General's CCPA overview explains, and per-user logs help answer those requests when agents touch personal data.
Every agent request passes through the connectivity layer, so Connect AI logs the requesting user, timestamp, source, and statement there. Business tier customers can forward those audit events to a security information and event management (SIEM) system in real time. Connect AI keeps log files for seven days, so longer audit windows require forwarding logs to the SIEM and matching retention to the audit period. The AI agent governance guide covers the wider framework.
Govern agent access to enterprise data with CData Connect AI
CData Connect AI enforces least privilege and audit trails where each agent request meets the source system. As a managed MCP platform, it passes each user's identity through OAuth and SAML, applies existing source permissions at request time, and logs every request across hundreds of systems, which answers the identity and privilege abuse risk OWASP describes. Security architects evaluating an agent rollout can start a free trial of CData Connect AI.
Frequently asked questions
What is MCP access control for agents, and why does it matter for enterprise security?
MCP access control governs identity, tools, data, actions, and auditability for agents connected to enterprise systems. Agents work at machine speed, so one over-broad permission exposes far more data than a human user would reach.
How is least privilege access control different for AI agents compared to human users?
Agents chain tool calls and run continuously, so permissions must narrow per task and per user instead of following a static human role. Each request then runs with only the access that task needs.
Should AI agents use a shared service account or their own identity for MCP access?
Each agent should act under the requesting user's identity. Passthrough applies the requester's permissions and records a named user, while a shared service account hides attribution.
What should an MCP agent audit trail log to satisfy SOC 2 or GDPR requirements?
The trail should log named user identity, agent identity, request or tool call text, systems and objects accessed, and a timestamp. These fields tie each action to a person, an agent, and a system.
Does MCP handle authorization on its own, or does it rely on a separate access control system?
MCP delegates authorization to OAuth 2.1 and a separate authorization server, and the spec treats it as optional. Source-system permissions and the identity provider supply the access decisions.
What types of access control should be applied to MCP agents, and how do they work together?
Identity and SSO establish who is asking, RBAC sets what that user may do, and tool allowlisting limits callable actions. Workspace isolation and environment separation limit reachable sources and keep pilots away from production.
How can organizations use MCP audit logs for SIEM integration and ongoing access reviews?
Export request-level logs to the SIEM for real-time alerting, then run periodic access reviews that compare logged activity against granted roles. Roles with no logged activity are candidates for removal.
