An AI agent doesn’t need to be malicious to become a security problem.
Sometimes, all it takes is a legitimate connection, too much access, and nobody checking whether that access still makes sense.
That’s the uncomfortable question emerging around the Model Context Protocol (MCP).
MCP makes it easier for AI applications to connect with tools, services, and data. But connecting an agent to a system is only the beginning. The more important question is what that connection allows the agent to access—and whether those permissions are appropriate for the task.
Because a permission that made sense when it was created may not make sense six months later.
The Access Problem Behind MCP
MCP gained significant adoption after its introduction by Anthropic in late 2024. Microsoft, Google, and OpenAI embraced the protocol, and its maintenance was later handed to the Linux Foundation.
As MCP adoption expanded, organizations began connecting AI agents to systems containing valuable information.
Repositories.
Workspaces.
Customer data.
Internal tools.
Business operations.
The integration itself may work exactly as designed.
But that doesn’t automatically mean the access model is secure.
A server can behave correctly while the credential behind it has access to far more data than the agent actually needs.
That’s where the security discussion becomes interesting.
The question isn’t only whether the protocol works. It’s whether the permissions underneath it are appropriate.
A Successful Connection Can Still Be Overprivileged
Imagine an AI agent that needs to read one repository.
The team creates a token, connects the agent, and everything works.
Months later, the agent still has access to multiple repositories, private resources, or organizational data that were never required for its original task.
Nothing necessarily broke.
No obvious error appeared.
The integration continued functioning.
But the access scope may have quietly become a problem.
This is one of the biggest challenges with long-lived credentials: teams often review access when they create it, but not necessarily when circumstances change.
And when an AI agent can act independently, excessive permissions become more concerning.
What Recent MCP Incidents Teach Us
Several security incidents discussed in the MCP ecosystem illustrate why authorization deserves more attention.
In May 2025, security researchers reported a GitHub MCP server vulnerability involving prompt injection and access to private repository data. The incident is relevant to the broader permission discussion because the access granted through the connected credentials mattered to the impact.
Another incident involving an Asana MCP integration raised concerns about cross-tenant data exposure.
These cases should not be reduced to a single explanation. A vulnerability may involve application logic, authorization design, credential scope, or more than one of these factors.
But they do highlight an important lesson:
Authentication proves who or what is connecting. It does not, by itself, establish what every action should be allowed to do.
That distinction is easy to overlook when an AI agent is treated like another software integration.
The Three Questions Every MCP Integration Should Answer
A secure integration needs more than a successful login.
It needs a clear answer to three questions:
- What identity is making the request?
- What is that identity allowed to access?
- How long should that access remain valid?
These questions are connected.
A credential can be correctly scoped for one task but remain active long after the task has changed.
An agent can have a recognizable identity but still possess excessive permissions.
And a system can require approval without properly limiting what happens after approval.
This is why MCP security is not just a matter of scanning for protocol vulnerabilities.
1. Stop Treating Permissions as a One-Time Decision
When a credential is provisioned, the access may be perfectly reasonable.
A developer needs access to a repository.
An agent needs to read a workspace.
An automation tool needs to perform a specific action.
The initial decision makes sense.
But what happens afterward?
Does the credential still need the same scope?
Has the agent’s responsibility changed?
Has the connected system gained new sensitive data?
Has the original task ended?
If nobody reviews the access, the original decision effectively becomes permanent.
That’s a problem for any integration—not only MCP.
A useful permission model should make it easy to answer:
What can this credential access today, and why does it still need that access?
2. Narrow the Scope Before the Agent Starts Working
An integration that provides access to an entire organization may be convenient.
It may also be more access than the task requires.
For example, an agent that needs to work with one repository shouldn’t automatically receive access to every repository in the organization.
The same principle applies to sites, workspaces, customer records, and other resources.
The goal is not to make every permission request complicated.
The goal is to avoid granting broad access simply because the integration makes it easy.
A good starting point is to ask:
- Can access be restricted to a specific repository?
- Can the agent operate within one workspace?
- Can it read data without being allowed to modify it?
- Can sensitive actions require separate authorization?
- Can access be reduced when the task is complete?
If the answer to these questions is always “everything or nothing,” that’s worth investigating.
3. Don’t Confuse the User’s Identity With the Agent’s Identity
This is where the problem gets more complicated.
An AI agent may be created by a human, authorized by a human, and connected using a human’s credentials.
But the agent itself may operate independently.
That raises an important question:
Is the agent actually a separate identity, or is it simply using the permissions of the person who created it?
These are not the same thing.
A user may have access to one set of repositories.
A token created for an integration may have broader access.
If the agent uses that token, its effective permissions may exceed what the user intended for the specific task.
This is why identity and authorization need to be designed together.
You need to know not only who approved the connection, but also which identity is responsible for each action the agent performs.
4. Temporary Credentials Make More Sense for Temporary Work
Not every agent needs to exist for months.
Many agents perform a short task:
Read some data.
Analyze a repository.
Create a draft.
Run a workflow.
Then stop.
For these tasks, a credential that lasts indefinitely may be unnecessary.
A more controlled approach is to issue credentials with a limited lifetime and a specific purpose.
When the task ends, the access should end with it.
This is the direction behind the broader push toward dynamic and temporary credentials.
The idea is straightforward:
The longer an agent lives, the more carefully its permissions should be managed.
A five-minute automation and a continuously running business agent should not automatically receive the same access model.
Agent Lifetime Is Becoming a Security Input
Traditional authorization systems were largely designed around human users.
A person logs in.
The person approves access.
The person uses the application.
But AI agents can operate differently.
They may run without continuous human involvement.
They may execute tasks repeatedly.
They may remain active for extended periods.
And they may interact with multiple systems through connected tools.
That creates a mismatch between older permission assumptions and newer agent-based workflows.
A credential designed for a human making an occasional decision may not be appropriate for an agent that can act independently for weeks or months.
This is why agent lifetime matters.
The security model should consider:
- How long will the agent exist?
- What tasks will it perform?
- What data will it access?
- Can its permissions change over time?
- Who is accountable for its actions?
The answer shouldn’t be an afterthought.
The Confused Deputy Problem
One of the recurring security concepts relevant to AI agents is the confused deputy problem.
The basic idea is that a system with legitimate authority can be tricked into using that authority on behalf of someone who should not have access.
In an AI workflow, an agent may have access to tools and credentials that exceed what a particular request should allow.
If the agent follows an instruction that causes it to use those permissions improperly, the issue is not necessarily that the underlying tool is broken.
It may be that the agent was given too much authority in the first place.
Another concern is tool poisoning.
A malicious or compromised tool description may contain instructions designed to influence the agent’s behavior.
These are different security problems, but both reinforce the same principle:
An AI agent should not automatically be trusted with every capability available through its connection.
What Should a Better MCP Permission Model Look Like?
A practical model would combine several controls.
Task-Based Access
Permissions should reflect the actual job the agent is performing.
A read-only research task should not require unrestricted write access.
Resource-Level Restrictions
Where possible, access should be limited to the specific repository, workspace, site, or data resource involved.
Action-Level Authorization
Authentication should not be the end of the authorization process.
Sensitive actions may need separate checks based on the requested operation.
Short-Lived Credentials
Credentials should expire when their intended use ends, rather than remaining active indefinitely by default.
Auditable Activity
Organizations should be able to identify which agent performed an action, under whose authority, and against which resource.
Reviewable Changes
Changes made by an agent should pass through appropriate review processes when the risk requires it.
For example, code changes may be created as a branch or draft before they are merged into production.
The point is not to make every AI workflow slow.
It’s to apply the same security discipline to agents that organizations already try to apply to human access.
The Hardest Part Is Not the Initial Setup
Creating a credential is relatively easy.
The difficult part is maintaining the access model as the system evolves.
An agent may start with a narrow purpose.
Then its responsibilities expand.
More tools get connected.
More data becomes available.
The credential remains unchanged.
Over time, the original permission decision no longer reflects the actual risk.
That’s why permission management should not stop at provisioning.
It needs ongoing review.
The organization should be able to explain why an agent has access today—not just why it was given access originally.
MCP Security Is Bigger Than MCP
It would be easy to treat every MCP security incident as a protocol problem.
But that would miss an important part of the picture.
MCP is a way for AI applications to connect to tools and data.
The security of those connections also depends on the authorization systems, credentials, identity models, and application logic underneath them.
Improving the protocol can help.
Better tooling can help.
Security scanners can help.
But none of those automatically solves excessive permissions.
If an agent is allowed to access more than it needs, the risk remains.
The Bottom Line
MCP is making it easier for AI agents to interact with real systems.
That is useful.
It also means that permissions deserve more attention than they have traditionally received in simple integrations.
The security question should not be:
“Did we approve this connection?”
It should be:
“Is this agent allowed to perform this specific action, on this specific resource, with this specific identity, for this amount of time?”
That’s a much stronger way to think about access.
Because the biggest risk may not be an obviously broken protocol.
It may be a perfectly valid credential that was granted for a good reason—and never reviewed again.
MCP security isn’t only about fixing vulnerabilities. It’s about making sure the permissions behind every connection continue to match the work the agent is actually supposed to do.
