Governing the agents your teams already use

Why this conversation

Few companies chose to run half a dozen AI agents. Different people gravitate towards different tools, and the agents end up running locally on many machines. For the people responsible for security and compliance, the first problem is not policy but visibility: knowing what is running, what it can reach and what it does. At AGNTCon + MCPCon Europe in Amsterdam, on 18 September, the host spoke with Andrew Linehan, who works in sales at RunLayer, an AI governance platform aimed mainly at enterprises that want to see and standardise AI use within the organisation. The rest of the week is in AGNTCon + MCPCon Europe 2026: who we met.

Five or six agents per company

These days, Andrew says, a company typically has five or six different coding harnesses and five or six different agents in use at any given time. That is per company, not per user: different people gravitate towards different products. Occasionally there is the user who is so enthusiastic about AI that they use all of the agents and all of the clients at once, which he doubts is productive from a token standpoint.

Asked which agent harness he sees most, he named Claude, whose agent harness he finds extremely popular, and Cursor. The capabilities of the harnesses are becoming fairly standard, so the choice is often a preference, and a consequence of the broader AI stack and vendor relationships a company already has.

From visibility to guardrails

RunLayer gains visibility through the company’s mobile device management platform. The IT manager installs a script that integrates with hooks in the agents running locally on people’s machines. From there RunLayer sees what happens in each session: the reasoning steps, the prompts the agent uses, the tool lists, the tool calls and the other actions.

The host called this the discovery phase, and Andrew agreed. It is the basis for control. With the information in hand, a team can set guardrails and policies, and decide the boundaries for each agent within the tools it can reach through MCP or through the underlying API. Those boundaries can be drawn in a very specific and granular way, for particular agents and for AI client use.

Agent accounts

Once an agent is known, there are two ways to go. It can be migrated to a RunLayer agent, managed there, with access to the tools, skills and infrastructure it is meant to have. Or it can stay independently managed and use agent accounts: non-human identities set up for specific agents, with access to specific tools and specific services within those tools. Limiting the scope that way keeps small the damage any one agent can do. The host compared it to role-based access, and Andrew agreed: role-based access control, extended to agentic use cases and agentic identities.

Trying it out

RunLayer has demo videos at runlayer.com, where people can also ask for a demo with Andrew or a colleague. The team can also set up a proof of concept with access to the tool in the RunLayer environment, so an enterprise can run it itself and see whether it fits.