Agent governance for teams: start with the boundaries a prompt can't move
IBM, NVIDIA and Meta made agent governance the headline this week. For a team running department and workflow agents, the useful question is simpler: which boundaries does the platform enforce, whatever the agent is told? In Kylon there are four.
In short. A governance rule written into an agent's instructions is only as strong as the model's willingness to follow it. A rule enforced by the platform holds whatever the agent is told. In Kylon, four boundaries are enforced that way: who can talk to an agent, who is in a private Room, whose account a connection is, and who an App lets in. Everything else in a workspace is designed to share context. A shared agent can safely sit in most private Rooms; the few Rooms that need hard isolation get their own private agent.
Governance became the headline this week
On October 27, IBM used TechXchange 2026 to announce identity and control for AI agents: a governed identity for each agent through HashiCorp Vault, least-privilege credentials with real-time revocation when an agent attempts an unauthorized action, and watsonx Orchestrate discovering and containing agents across Amazon Bedrock, Microsoft Foundry and Google Gemini. The same release cites Gartner: by 2028 the average Fortune 500 enterprise will use over 150,000 AI agents, and only 13% of organizations believe they have the right agent governance in place.
The same day, NVIDIA and Meta said they would expand their work on Muse and the Muse family of models, and may explore NVIDIA's OpenShell framework for safe rollout and a tool called Sentry to monitor how agents behave. A week earlier NVIDIA had launched the OpenShell Reference Architecture, where Sentry runs on BlueField DPUs and quarantines an agent that tries to move outside its software boundary.
These are answers built for companies with thousands of agents across clouds, identity providers and data centers. A team of twenty running agents in one workspace meets the same questions on its first day, just at a smaller scale.
The question a customer asked us
A customer put it this way. They have agents per department and agents per workflow. Some workflow agents run across several departments, and each department should see different data from the same agent. Then come the governance questions: who creates an agent, who decides what it can use, which employees are allowed to manage agents at all. And the one underneath all of them:
Once we write all of these rules down, can someone jailbreak the agent and change them? Our president holds the highest permission. Could someone talk an agent into handing it over?
The worry is fair. If the rules live in the agent's instructions, they are loose. A good prompt injection rewrites what the model tries to do.
A rule in a prompt and a rule in the platform
A jailbreak changes what an agent attempts. It does not change what the platform lets that attempt reach.
In Kylon, every request goes through the same access check, whether a person or an agent sends it. The check runs outside the model, so the answer to "can this request read that Room" is the same however the request was phrased. Our privacy architecture post goes deeper on why we treat the model as untrusted input.
So the practical governance question becomes: which boundaries does the platform enforce? There are four.
The four hard boundaries
1. Who can talk to an agent
Every agent has its own access list, separate from workspace membership. A new agent starts private, with nobody on it but its creator. Members can use it; Admins can also change roles and switch on workspace-wide access, and an agent always needs at least one human Admin.
This is the boundary that answers the question about the president's permission:
- Workspace admins do not bypass an agent's access check, and are not let into private Rooms or agents they were not added to.
- An agent can prepare an access-change request, but the person named on the card must approve it; asking an agent to share itself does not bypass these roles.
- Creating agents and approving cards are reserved for people, along with sending a draft and revealing a stored key.
- An agent working for you can call on only the agents you can use, so a chain of agents reaches no further than the person who started it.
2. Who is in a private Room
A private Room is invite only. An agent reads the thread it is working in and searches the Rooms it has joined, and nothing else, public Rooms included.
The check follows the person, not the agent. An agent reads a private Room's messages from somewhere else only when it is working for someone who is a member of that Room. Say a workspace-wide agent sits in a private finance Room. A colleague who is not in that Room asks the same agent about finance from a public Room. The agent is working for that colleague, so the finance Room's messages are out of reach for this request. Being in the Room does not turn the agent into a way around it.
3. Whose account a connection is
A connected Gmail, CRM or bank login belongs to the person who connected it. A connection is not automatically available to every agent; its access setting decides who can use or manage it. For an agent to keep using a connection on its own, it requests persistent access with an approval card, and the authorized person decides.
4. Who an App lets in
Structured business data, such as member records or finance stages, belongs in an App. Every App has its own database, its server can use only the connections granted to that App, and every server call checks that the viewer is still allowed in. When different audiences should see different records, put the sensitive data in its own App with a narrower audience.
What a private Room does not cover: what the agent writes down
The Room boundary covers the Room's messages. It does not cover what the agent decides to keep for itself.
An agent can save what it learns into its own memory, or into notes and files it keeps. That memory belongs to the agent, not to the Room. An entry scoped to a Room loads in full only there, but the agent sees a one-line summary of every entry, and anyone with access to that agent can read its memory. So if a shared agent in a private Room writes down "the Q4 budget was cut by 20%", a colleague outside that Room could later get that fact from the agent, even though they still cannot open the Room. This is why Kylon warns you, when you add an agent to a private Room, that it can use what it learns there in other Rooms.
That is a probability, not a certainty: it depends on what the agent chose to remember. For most Rooms that is fine. For a few it is not.
Two kinds of private Rooms
Most private Rooms: inviting a shared agent is fine. Many Rooms are private to keep a project focused, a client's work tidy, or a small team's noise out of everyone's feed. The people on the shared agent's access list are colleagues who could know the gist anyway. The Room's messages stay gated by membership, and an occasional remembered fact reaching a teammate does no harm. Here the shared agent's context is the point: it can connect this work to the rest of the company.
Rooms you want hard isolation for: give them their own agent. Pay and HR cases, member or customer personal data, finance before it is announced, legal matters, deals under NDA. If even a one-line summary reaching someone outside the Room would be a problem, do not invite a workspace-wide agent. Create a private agent for that Room, put exactly the Room's members on its access list, and keep the related records in an App shared with the same people. Then the agent's memory has the same audience as the Room.
The question to ask before inviting an agent: if this agent remembered something from here and mentioned it to anyone on its access list, would that be a problem? If not, invite the shared agent. If so, give the Room its own.
Applying it to department and workflow agents
| What the team wants | How to set it up |
|---|---|
| Each department has its own agent | One private Room per department, and a department agent whose access list is that department |
| A workflow agent spans departments | Keep the cross-department steps in a shared Room with the workflow agent. It can also sit in departments' everyday private Rooms, since their messages stay gated by membership |
| Some data must stay inside one department | Handle that step with the department's own private agent in its private Room, and keep the records in an App shared only with that department |
| Only certain employees may create or manage agents | Agents are created by people, each agent has named Admins, and only Admins change roles |
| Nobody can talk their way into the top permission | Access changes go through an approval card the named person signs; workspace admins do not inherit private Rooms or agents |
Where enterprise tooling fits
IBM's and NVIDIA's announcements work at the identity provider, credential, runtime and hardware layers, for organizations that need to find and govern agents built on many platforms. A team running its work in one workspace needs the same four answers, enforced where the agents actually work: who can use this agent, who can see this Room, whose account is this, who can open this App.
A five-minute check for your workspace
- List your private Rooms and mark the few that need hard isolation.
- In each of those, open the agents' Access tabs. Is everyone on each list also a member of that Room? If a workspace-wide agent is in one, give that Room its own private agent.
- Check that every agent has at least one named human Admin you would trust with that data.
- Open your Connections and review who each one is shared with.
- List the Apps that hold sensitive records and confirm each one opens only to its intended audience.
Related reading: How permissions work in Kylon walks through each setting on screen, and Kylon's privacy architecture covers isolation below the workspace.
Your first company harness. Where humans and agents run your business together.
