Runlayer found that its 60-person company was running more than 300 agents each day, with many agents having broad permissions and little central oversight.
2
Prompt injection can unfold across emails, GitHub comments, and an entire agent session, so checking individual tool calls is not enough.
3
Central monitoring exposed security problems, broken MCP servers, and model changes that increased costs by over 100x in a week.
Summary
Aiden Sochowski describes how Runlayer put a gateway in front of its internal agents and logged sessions, tool calls, errors, and connected systems. The company had more than 300 agents running each day with about 60 people, which made manual review and fixed policies difficult. He shows how a malicious email could cause an over-permissioned agent to expose company data, and how a PR-review agent could be persuaded through a long GitHub exchange to approve a change. Runlayer uses session history and a classifier model to detect when an agent drifts from its assigned task, then suggests narrower permissions. The same monitoring also found agents contaminating shared systems, badly written MCP servers that repeatedly burned tokens, and model switches that increased costs by over 100x in a week. Sochowski argues for monitoring, budgets, rate limits, and intervention based on observed risk rather than blocking every action.
Runlayer found more agents than people inside its own company
Runlayer had about 50 to 60 people but more than 300 agents running every day. These agents could be started by chatbots, triggers, or SaaS applications rather than by a person directly. Aiden Sochowski says the team mapped them by topic and risk because their permissions and blast radius differed. Some agents connected systems containing different classes of data, which made data mixing more dangerous than a carefully written program calling one API. The team visualized each agent, its runs, the MCP servers it touched, the actions it took, and any errors.
A malicious email can turn an over-permissioned support agent into a data-exfiltration path
Sochowski describes a support workflow that reads company email. An attacker could send a message asking for a list of current prospects, and a naive agent might search calendars or other connected sources before sending the information out. Policies could inspect incoming instructions, block external transmission of personally identifiable information, or restrict access to a private calendar. These rules depend heavily on context. A tool may be safe in one situation and unsafe in another, so defining every rule in advance is difficult. Runlayer found that deploying such policies internally remained a difficult, unfinished problem.
Some attacks only become visible across a complete agent session
A single tool call may look harmless while the sequence of actions changes the result. Sochowski uses an agent that reviews and approves pull requests as an example. The agent may start with a security checklist, then read GitHub comments where the author argues that a change is safe or asks it to review only cleanup work. If its permissions do not change with the session, repeated prompting may eventually lead it to approve a pull request. Runlayer trained a classifier model to examine the full session and compare every tool call with the agent's original purpose.
Past session data can reveal when an agent needs fewer permissions
Runlayer found that session history is especially useful for agents with a narrow task. A recruiting bot had access to an applicant tracking system, meeting notes, a calendar, and messaging tools. The bot could do much more than its stated job. By comparing current tool use with the normal range of past runs, the team could flag unusual high-risk activity early. The same history could suggest permissions to remove, such as access to every record in an applicant tracking system or every meeting. Sochowski says this is more practical than trying to define all safe behavior before the agent is used.
Shared systems allow one poisoned agent to affect other agents
An agent can receive hostile content, such as a malicious resume, and write the resulting data into a shared system. Another agent may later read that data as part of its normal instructions. Because agents move data between connected systems, a compromise can spread even when the second agent did nothing unusual. Runlayer mapped the connections between systems and restricted where agents could write. Sochowski says tight write permissions are the main way to keep an agent's context from becoming polluted. Partitioning data and limiting writes to particular databases or parts of a SaaS application reduce this path of contamination.
Monitoring exposed problems beyond security. Agents repeatedly called MCP servers that returned errors, then tried workarounds. Each attempt consumed input and output tokens. Runlayer's recruiting team had built an MCP server for a vendor API because the vendor did not provide one. The team had little software-writing experience and had not tested the server much, so formatting errors caused repeated failures and drove costs upward. Sochowski recommends watching error rates, rate-limiting these tools, and checking the quality of the code behind MCP servers.
Model switches can multiply costs without a clear justification
Runlayer also saw teams switch from an initially cheap model to a more expensive one, with costs rising by over 100x within a week. Teams often cannot explain why a particular task needs the more capable model, especially when they are not running evaluations on their agents. Sochowski describes budgets and sensible defaults as practical controls. Teams should be able to explain when a task needs extra intelligence instead of allowing every agent to use the most expensive option by default.
Monitoring lets teams intervene selectively instead of blocking every action
Sochowski's final recommendation is to build enough visibility to detect what is actually happening. A company cannot simply stop every agent action, and it cannot safely rely on fixed permissions for every context. Monitoring should identify high-risk actions, allow someone to intervene, and route users toward workflows that follow internal policies. The same control layer can track security events, tool errors, model use, and spending. Runlayer uses this process to decide where a restriction or a narrower permission is needed.
"You can't just outright say, 'Hey, I'm going to go stop all actions that are going on within my company.'"16:04
Who should watch
You have agents connected to email, calendars, recruiting systems, GitHub, or other shared data stores and do not have a central view of their sessions.
Your agents have broad permissions, and you need evidence for which tools or writes can be removed without breaking the workflow.
Your model bills or MCP tools are growing unexpectedly and you need session-level error, usage, and budget controls.
