DLP and RBAC for AI Agents: Why MCP Servers Need Security That Frameworks Won't Give You

When an AI agent queries a customer database and passes the results to a language model, who checks whether those results contain social security numbers, credit card numbers, or protected health information? In most agent frameworks, the answer is: nobody. The data flows from database to model to output without any inspection.

When an AI agent has access to 50 MCP servers with 200+ tools, who determines which users can invoke which tools? In most MCP deployments, the answer is: the MCP server config file, which grants blanket access to anyone who can reach the server.

The platform addresses both of these gaps with two integrated systems: the DLP Scanner for data protection and RBAC for per-tool permission granularity.

The DLP Scanner

The DLP (Data Loss Prevention) Scanner inspects data at two critical points in the agent execution pipeline:

Pre-Model Scanning

Before any data reaches a language model, the DLP Scanner checks for sensitive data patterns. This matters because once sensitive data is sent to a third-party model provider, you have lost control of it. Even if the provider promises not to train on your data, the data has left your perimeter.

The scanner is designed to detect a broad range of sensitive data classes, including:

• Social Security numbers, national ID numbers
• Credit card numbers (PCI DSS compliance)
• Protected health information (HIPAA compliance)
• Email addresses and phone numbers
• API keys, access tokens, connection strings
• Personally identifiable information (PII) across multiple jurisdictions

When the scanner detects sensitive data, it can take several actions based on policy:

• Redact: Replace the sensitive value with a placeholder before sending to the model
• Route: Send the request to an on-premise model instead of a cloud provider
• Block: Reject the request and log the attempt
• Alert: Allow the request but notify the security team

Post-Model Scanning

The scanner also inspects model outputs before they reach the user or downstream systems. If a model hallucinates a real credit card number or reproduces PII from training data, the scanner catches it before it propagates.

SmartModelRouter Integration

The DLP Scanner integrates with SmartModelRouter to enforce data routing policies. A policy might specify: “requests containing PII route to the on-premise Ollama model only.” SmartModelRouter honors this policy automatically, overriding the normal routing logic when sensitive data is detected.

RBAC: Per-Tool Permission Granularity

MCP servers do not have built-in access control. If you can reach the server, you can call any tool it exposes. This is fine for local development. It is not fine for enterprise deployments where different users, teams, and roles should have access to different capabilities.

The platform's RBAC system provides permission granularity at the tool level:

• User-level permissions: Which capabilities a specific user can invoke. User A can call the GitHub capability. User B cannot.
• Team-level permissions: Inherited permissions for team members. The Engineering team has AWS capability access. The Marketing team has Slack and HubSpot.
• Capability-level controls: Each capability (GitHub, Slack, AWS, filesystem, etc.) can be set to enabled, disabled, or require_approval per scope.
• Approval authority: Who can approve HITL gates for specific capabilities. Junior engineers can approve read-only tool executions. Only senior engineers or team leads can approve write operations. Only security staff can approve critical operations.

How It Works with Credential Isolation

RBAC and credential isolation work together. RBAC determines whether a user is permitted to invoke a capability. Credential isolation determines what the tool can actually do with scoped, time-limited tokens. Both must pass for a tool execution to proceed:

1. RBAC checks: does this user have permission for this capability? If no, reject.
2. HITL gate checks: does this capability require approval at this risk level? If yes, pause for approval.
3. PlatformCredentialInjector generates a scoped credential for the specific operation.
4. The tool executes in a sandbox with only the scoped credential available.
5. Credential is revoked. Audit event is recorded.

Why MCP Servers Cannot Provide This

MCP (Model Context Protocol) defines how AI clients communicate with tool servers. It does not define authentication, authorization, or data protection. These are explicitly out of scope for the protocol. This is a reasonable design decision for a protocol standard — but it means every enterprise deploying MCP servers needs to add security themselves.

In practice, most MCP servers are deployed without:

• Any form of authentication (no API keys, no OAuth, no mTLS)
• Any form of authorization (all tools available to all callers)
• Any form of input validation (whatever the client sends, the server executes)
• Any form of data protection (sensitive data flows freely between model and tool)
• Any form of audit logging (actions are not recorded)

This is why we built DLP and RBAC at the platform level. MCP servers should not need to implement security individually. The platform layer should enforce security across all MCP servers, all OATS-synthesized tools, and all agent interactions uniformly.

Platform-Level Security

DLP and RBAC are two components of the platform's security architecture. They work alongside credential isolation (scoped tokens), sandboxed execution (isolated environments), HITL gates (human approval), the Audit System (immutable logging), and SmartModelRouter (provider-level routing policies).

The principle is consistent across every component: security is a platform concern, not an application concern. Individual tools, MCP servers, and agent implementations should not need to implement their own security. The platform enforces it uniformly, audits it completely, and makes the secure path the default path.