AI Agent Identity Security: Trace the Path Behind Every Tool Call

The short answer

AI agent security depends on more than the permissions shown in the agent's own settings. To understand effective access, trace the full path: who can invoke the agent, which identity the agent uses, which connector or MCP tool it calls, and what the downstream service allows that identity to do.

An agent can become a bridge between a low-privilege user and a more privileged connection. The risk appears in the relationship between those components, even when each setting looks reasonable on its own.

Map the identities, not just the agents

For each production agent, record the principals at every hop:

This map should include delegated flows and agent-to-agent calls. When execution moves to a new identity, record the transition instead of treating the workflow as one continuous user session.

Three access paths that deserve a test

1. A user invokes an agent that acts as its maker

An employee may be allowed to use an agent without having direct access to every resource available to the agent's owner. If the agent uses the owner's connection for outbound actions, the destination sees the owner's authority. Test whether the server checks the original caller's rights as well as the connection identity.

2. An anonymous agent reaches an authenticated resource

Public invocation can be intentional. It becomes risky when the agent uses a stored authenticated connection to read or change data. An unauthenticated caller may then be able to reach capabilities backed by a trusted identity. Validate the combined path with synthetic data and a non-production resource.

3. An MCP tool expands what an agent can do

An MCP server may connect an agent to files, internal APIs, tickets, or databases. Cyber Security News reported internet-wide reconnaissance for MCP handshakes and exposed AI services in July 2026. The article describes correctly formed initialization messages used to identify reachable MCP services, which is a reminder to treat exposure and authentication as basic attack-surface controls.

The service being reachable is only the first question. Review the tools it advertises, the identity used for each call, the data returned, and whether a tool can write or trigger a second workflow. A read operation can still leak tenant data; a write operation can create a direct integrity or availability impact.

Test effective authorization end to end

Use a small test matrix with separate accounts and synthetic records. For every agent action, compare what the caller may do directly with what the agent can do through its downstream connection.

1. Invoke the agent as a user who lacks direct access to a canary record.
2. Ask for a read and a write through each relevant tool, including indirect or chained requests.
3. Confirm that the destination denies unauthorized actions, even if the agent proposes them.
4. Repeat with a different tenant and verify that neither retrieval nor tool output crosses the boundary.
5. Review logs to confirm the caller, execution identity, connector, resource, decision, and final state are recorded.

Do not accept a denied prompt as evidence that authorization is secure. The control must live at the API or tool boundary, where a model cannot override it. Likewise, a successful read is not automatically a vulnerability; demonstrate that the caller was not supposed to access that resource and preserve a safe, reproducible trace.

Controls that break the path

• Prefer delegated, user-scoped authorization over maker credentials or shared high-privilege identities.
• Separate read and write tools; require approval for high-impact actions.
• Bind credentials to a tenant, audience, resource, and short lifetime.
• Put MCP services behind authenticated gateways and private network controls unless public exposure is an explicit requirement.
• Give each connector only the scopes needed for its workflow and verify permissions at the destination.
• Restrict who can publish agents, edit tool definitions, or change connection ownership.
• Log identity transitions and revoke sessions or tokens through an incident-response path.
• Test indirect prompt injection as an untrusted-input problem, while keeping authorization enforcement outside the model.

SpecterOps' work on Entra agent attack paths emphasizes the gap between the identity that invokes an agent and the identity it ultimately uses. The operational takeaway is to review how those identities and permissions compose across services, rather than approving an agent based only on its inventory entry or owner's role.

A practical review output

For each finding, document the starting principal, the agent and connector, the identity transition, the target resource, the missing check, a safe proof, and the smallest remediation that closes the path. Then retest the same sequence. This gives the identity, AI platform, and application teams a shared action they can verify.

An AI agent security assessment should cover these identity paths alongside prompt injection, retrieval isolation, tool design, and runtime limits. If you operate MCP integrations, include MCP security testing in the scope.

Sources

• SpecterOps: Attack Path Management for Entra Agents
• Cyber Security News: Internet-wide scans target MCP servers and exposed AI models
• SpecterOps: Designing an MCP Server for AI Agents