MCP security is controlling what AI agents can reach through the Model Context Protocol: which tool servers they connect to, who each call acts for, which tools it may use, and where the credentials behind it live. The rule that holds it together: give agents the actions they need, not the credentials behind them.
Secure Connectivity is the part of the Autonomous platform that does it. MCP servers sit behind a gateway, the ones we host each in an isolated sandbox. Each tool is allowed or blocked for your organization, people can sign in to connected apps as themselves, and the tokens stay in a vault the agent never sees.
To call GitHub, Slack or a database, an agent needs a credential, and the usual answer is to hand it one: an environment variable, an API key in its MCP configuration, a token from a secrets manager. Those keep the secret out of the prompt, but not out of the agent's reach.
The safe path is the agent's choice
An agent calls an API with a token from an environment variable, so the model never sees its value. The call fails with a 401. Debugging the way a developer would, or following an instruction planted in a file it read, the agent prints the variable, and the token is now in its context, its transcript and every log downstream.
Holding the credential also gives the agent everything the credential allows, not only what the task needs, and when many agents share one service account, the logs can't say which agent acted or for whom.
It isn't hypothetical. In over 100,000 real agent sessions on enterprise endpoints:
Source: The Hidden Security Risks in 100k Enterprise AI Sessions
The fix is architectural: keep the credential on the far side of a component that decides each call. The agent can ask for the action; it can't take the key.
A tool call's path, in order. On one side, the AI agent, holding its prompt and history but never the app's token. On the other: the gateway, which first checks that the tool is allowed and who is calling, and audits the call; the token vault, which holds the OAuth token and releases it for this call only; the MCP server, hosted in its own isolated sandbox or remote and proxied, which uses it for the call; and the app behind it, which checks it. The agent never holds the credential.
An administrator adds each MCP server to the gateway once, from a vetted catalog or your own, and shares its endpoint with Claude, ChatGPT or Microsoft 365 Copilot. Hosted servers run in an isolated sandbox; remote ones are proxied and governed.
Where a remote server signs in with OAuth, each person connects their own account, so the agent works with their data and permissions, narrowed by the scopes set for their team. The tokens go straight into the vault.
When the agent calls a tool, the gateway checks the tool is allowed, the vault releases the token for that call alone, and the call is recorded with who made it and how it ended.
Every call through the gateway is recorded with who made it, and where an app lets each member sign in, the agent acts with that person's own access. Who that person is comes from the sources you already trust.
Your identity provider, license rosters, device management and the AI apps themselves each say who acted. You put them in order: the primary directory names people and wins when sources disagree.
For a remote app that signs in with OAuth, every member can connect their own account, so each gets their own data and the app keeps enforcing their own permissions. Or choose one shared credential for the whole organization.
For a remote app where each member signs in, set the most it may ever ask for, carve that into presets such as read-only, and map your identity provider's groups to them. A read-only team never consents to write access it doesn't need.
The gateway is where your organization's MCP servers are governed, each with an endpoint your AI platforms connect to. Instead of everyone assembling their own servers on their laptops, an administrator provisions them once, decides which tools each app exposes, and every connection and OAuth event is audited, with severity and outcome.
And what an agent does on the laptop itself, its shell commands and files, the endpoint agent and its guardrails cover, so one platform governs both.
A token vault is a store built for containment rather than quick access: it holds the credentials agents use and releases each one only at the moment of a call.
When you connect an app such as Slack or Gmail, its OAuth tokens are stored in a dedicated vault, apart from application data, and injected only when a tool call needs them. The agent, its prompt and its history never contain the secret.
We assume any MCP server we run, including one you upload, could be malicious. The vault is never directly reachable from it, each hosted server runs in its own sandbox and can't reach other servers, spaces or customers, and uploaded code is scanned for exfiltration patterns before it runs.
Encrypting a database protects lost disks, not an application that is breached and decrypts as usual. The vault constrains who may read each secret, and the API keys that connect agents are stored hashed.
Most agent tasks only need to read. Two controls keep it that way: what the agent may call, and what the sign-in behind it may do.
When a server labels its tools, the gateway groups them as read-only, write or delete, and other. Allow the read-only group and block the rest in one move, or set any tool on its own.
For a remote app where each member signs in, a read-only scope preset means the token itself can't change anything, even if a tool slipped through: the target system refuses it.
MCP servers people run on their own machines get the same kind of policy through the endpoint agent, enforced inline in the AI agents that support hooks: keep a server and block its one destructive tool, or allow only its read and list tools.
The Model Context Protocol is an open standard for connecting AI agents to tools and data. An MCP server exposes tools, such as searching a repository or sending a message, that an agent like Claude, ChatGPT, Cursor or Claude Code can call. MCP security governs those calls and the access behind them.
The client attaches the key to requests, so the agent doesn't normally read it, but the key still sits on the machine where the agent and the tools it runs can reach it, a project's configuration can be committed by mistake, and one file often holds keys for several servers. Behind a gateway, the key never reaches the machine.
An AI agent calling tools is a non-human identity: software acting with access. Autonomous doesn't give agents identities of their own to manage. Every call through the gateway is recorded with the person who made it, as your identity provider names them. Where an app lets each member sign in with their own account, the call is also limited to what that person may do there.
Yes. On the gateway, allow a server's read-only tools and block its write and delete tools, or set each tool on its own. For remote apps where each member signs in with OAuth, a read-only scope preset for a team means the token itself can't write.
The endpoint agent finds the MCP servers each AI agent loads, scores them for risk and applies your policy to them. Finding the AI tools nobody approved is Shadow AI.
Yes. Users and groups sync from Okta or Microsoft Entra ID, and devices from CrowdStrike Falcon, Microsoft Defender or your MDM. Audit logs stream to Splunk, IBM QRadar, OpenTelemetry, Syslog or Coralogix, and findings reach Slack or any webhook.
By default, the prompts, tool calls, responses and session metadata of the AI agents, for audit and investigation. You can set prompts and tool calls to keep only the verdict and metadata, only flagged activity, or nothing, and turn the other kinds off; a block is always recorded. Personal accounts can stay private: collect in full from your approved organizations only, and from personal or unknown accounts we collect metadata alone, their prompts and transcripts never leaving the machine. Seeing the content takes a role that allows it, and the browser extension hashes conversation text rather than storing it.
AI agents need access to sensitive systems, but they should not need the credentials behind them. This article compares common credential approaches and explains how OAuth and gateways can keep secrets outside the agent while enforcing identity, policy, and audit at the point of action.
Read More
This post explains how we safeguard our customers' secrets in today's integrated world of agents and MCP servers.
Read More
This guide provides a practical checklist for compliance teams to ensure MCP and AI integrations drive innovation without compromising business privacy or security.
Read MoreSee how Autonomous governs the MCP servers your teams use, and keeps every credential out of agents' reach.
Book a demo