MCP gives agents a universal way to connect to tools and services, but existing security models lose identity across delegation chains.
2
All-or-nothing permissions can give an agent access to sensitive data or financial actions when it only needs a narrow capability.
3
Identity-chain tracking, context-aware policy engines, detailed audit logs, and anomaly detection can limit and investigate agent-to-tool activity.
Summary
Rosemary explains MCP as a universal adapter that lets AI applications connect to databases, Slack, GitHub, file systems, and internal APIs. The security problem is that MCP deployments often apply human-oriented controls to systems where agents delegate work to other agents. Identity can disappear, permissions can cover far more data than a task requires, and audit logs may show only a service account accessing a resource. She connects these failures to an attack report involving an agent that autonomously attacked 30 organizations after being jailbroken. Her proposed controls include identity-chain tracking from the original user through sub-agents, context-aware permissions enforced by a policy engine, logs containing request IDs and decision reasons, and anomaly detection based on normal behavior. In the questions, she recommends OpenTelemetry for traces and spans, plus role-based tool context that blocks an agent from using tools outside its task.
MCP gives agents one connection layer for many tools
Rosemary describes the Model Context Protocol as the "USB-C port for AI." It lets an AI application connect to external data, tools, and services without separate integration code for every system. Her example has a personal assistant connected through an MCP protocol and host to Notion, Gmail, Slack, and Google Calendar. The same pattern can extend to databases, file systems, GitHub, and internal APIs. This makes multi-step work easier to build, but it also creates one agent pathway into many resources.
Delegation can erase the identity of the human and agents involved
MCP systems often preserve human trust assumptions while agents delegate work across multiple tools and systems. Rosemary says the agent identity can vanish during that process. A log might show Agent A calling Agent B, Agent B making a decision, and an MCP server using a service-account API key to access a repository. It does not show which human started the work, which agent spawned another agent, or which agent made the final call. If Agent B goes rogue, the operator may have to shut down the whole service because the system cannot revoke that agent surgically.
Broad permissions expose data far beyond the task an agent was given
Rosemary uses an inventory agent to show the problem with yes-or-no permissions. The agent only needs to check whether product 42 is in stock, yet access to the database can also expose customer PII, financial records, pricing algorithms, orders, payments, analytics, and secrets. The security boundary is much wider than the task. In this model, the agent either has access to the database or does not. It cannot receive access only to the inventory information required for the request.
Basic audit logs lose the reasoning and delegation chain
When a main agent spawns a sub-agent to run a SQL query, a simple log may say that a service account accessed the database at 10:42 a.m. Rosemary says this loses the conversation ID, original user, original question, sequence of decisions, justification, and identity of the sub-agent that made the call. After a leak, investigators cannot easily tell whether the cause was a malicious prompt, an accidental decision, or prompt injection. Without the decision history, replaying the agent's logic becomes difficult.
Identity-chain tracking makes actions traceable and revocable
Rosemary recommends logs that preserve the full chain from user to agent, sub-agent, and resource. This lets an operator trace an action back to the originating conversation and revoke access at different levels. The operator could stop one sub-agent or terminate the entire chain. She also describes behavioral analysis that can notice when an agent performs an action it does not normally perform, such as accessing a database directly, and shut it down for investigation.
Context-aware permissions evaluate the action in its situation
A context-aware permission system does more than ask whether an agent has access to Stripe. It sends the request through a policy engine that checks the context and policy rules before allowing the action. Rosemary's example is a refund request that exceeds the configured limit. The system records the decision and reason, then returns an action-denied result without touching Stripe. This gives the policy engine a chance to distinguish an allowed capability from an allowed use of that capability.
Detailed logs and anomaly detection support investigation
Rosemary recommends recording the request ID, identity chain, justification, action, policy decision, decision reason, rules, and timestamp. These records can trace a request from the user's question to the database query and support replay of the decision tree. Anomaly detection can also compare a request with normal behavior. If an agent usually returns 500 rows but suddenly requests 50,000, the system can flag the volume even when the credentials and policy technically allow the request, then stop or isolate the activity.
Tool context and OpenTelemetry add controls around agent behavior
In the questions, Rosemary says agents should receive role-based tool context. An agent can technically see available tools, but policy should stop it from using a database when its role is note-taking. She recommends placing a policy engine, context checks, and behavioral analysis between the agent and MCP tools. For audit data, she points to OpenTelemetry, whose traces and spans can be saved as the basis for custom detection models. She also says anomaly detection depends on the patterns and logs collected for the specific agent and MCP system.
"You have no idea which human started it, which agent spawned into what, which agent even made the call, which tools."03:02
Who should watch
You are building MCP-connected agents that can reach databases, communication tools, repositories, or financial systems, and need to define controls before deployment.
Your current logs show service accounts or tool calls but do not preserve the original user, delegated agents, policy decision, or reason for an action.
You need an approach to stop unusual tool use and build anomaly detection from traces and spans.
