Kylon for agent governance
Who can act, through which account, and who approves.
An agent that only writes text needs no governance. The moment it reads a CRM, sends through a mailbox or changes a record, three questions decide whether it can be trusted with real work. Kylon answers them in the workspace itself rather than in a policy document.
The product, running
Review is a control in the conversation, not a policy page
The agent has already read the sources it names and prepared what it would change. Nothing is applied and nothing is sent. The approval sits in the same thread as the request, so the person approving can see the evidence without leaving the room.
Interactive. Open the draft and approve the updates. Companies, people and figures are invented.
The four places governance actually lives
None of this is a separate console. It is the same workspace the work happens in, which is why the person approving can see what the agent read.
Identity and role
An agent is a member, not a feature: its own profile, its own name in the thread, its own rooms. You can see which agent did a thing, the way you can see which person did.
Attribution is on the message, not in an export.
Authorized connections
Agents act through accounts the workspace granted them, across the services you already run. A grant is given per connection and can be taken back on its own.
Revoking one grant does not disturb anyone else's access.
Memory and context
Durable memory keeps what was decided, so the same instruction does not have to be re-pasted every session. What an agent can reach is bounded by the rooms and connections it was given.
Context comes from the workspace, not from whatever was pasted in.
Approval and run history
Consequential work stops as a draft or an approval card in the conversation, and saved workflows keep their run history so a later question about a run has an answer.
A person releases the action, and the record of it stays in the room.
Four questions buyers now ask about agents, and the primitive that answers each.
Okta put the questions this way on 22 September: where are my agents, what can they do, what are they doing, and how do I respond. SAP calls the same work agent operations, IBM starts from agent identity, and Salesforce packages it as a control plane. In Kylon each question lands on one part of the workspace.
Where are my agents?
Rooms. An agent is a member of the rooms it works in, with its own name on every message.
What can they do?
Connections. Each account is granted for one job and revoked on its own.
What are they doing?
Threads and run history. The request, the sources, the approval and the change stay in one place.
How do I respond?
Approval and pause. Sends and record changes wait for a person, and one workflow or one grant can be stopped alone.
What the workspace controls
- Membership. Agents are workspace members with identity and profiles, so their work is attributed to them.
- Permission tiers. Admins, members and agents get distinct permissions, set per room and per App.
- Connections. Agents act through granted accounts across 3,000+ services, and each grant is revocable on its own.
- Approval. Sensitive actions wait as drafts or approval cards in the conversation until a person releases them.
- History. Workflow runs keep their record, and the thread keeps the reasoning next to the result.
Where the result goes
- CRM
- Salesforce · HubSpot · Pipedrive · Close · Dynamics 365
- Tasks
- Linear · Jira · Asana · Trello · ClickUp · monday.com
- Docs
- Notion · Google Docs · Google Sheets · Confluence
- Comms
- Slack · Gmail · Outlook · Microsoft Teams
How it works
- 01
Put the agent in the rooms where that work belongs, and nowhere else.
- 02
Grant the connections the job needs, at the scope the job needs, and revoke what it no longer uses.
- 03
Decide which actions require a person, and keep the approval in the conversation where the evidence is.
What Kylon does not do
This page describes how permissions, approval and run history work in the product. It is not a compliance statement, and it does not answer procurement questions about certifications, audits or data residency. Ask us directly for those and you will get a straight answer from a person.
Questions people ask
- What is AI agent governance?
- The set of answers to four questions about an agent that does real work: who it is, which accounts it acts through, what it is allowed to reach, and which of its actions need a person before they take effect. In Kylon those answers are properties of the workspace, so they hold for every agent in it rather than being restated in each prompt.
- How is an agent's access different from giving it my API key?
- A pasted key carries everything that key can do, and it is hard to take back without breaking other things. A connection is granted to the workspace, used by the agents you allow, and revoked on its own. The agent acts through the account you chose for it.
- Which actions require human approval?
- The ones you decide are consequential. Outbound email stops as a draft. Actions that change records or reach outside the workspace can wait on an approval card in the conversation, so the person approving sees the evidence and the proposed change together.
- Can I see what an agent did after the fact?
- Yes. Work happens in threads, so the request, the sources the agent named and the result stay together, and saved workflows keep their run history. That is the same place people already discuss the work, rather than a separate audit view.
- Can a tool's own description steer which tool an agent picks?
- It can. Researchers showed on 23 September that agents choosing tools from third-party servers can be drawn to a tool by its name and description, then steered by what it returns. That matters more as workflows call outside tools as a native step. In Kylon an agent works through the connections granted for its job, a send or record change waits as a draft or approval card beside the sources the agent named, and run history shows what each run did.
- Where does process knowledge live when agents run the process?
- UiPath's Cartographer keeps a Map of Work with a named owner who approves every change, and Valtech codifies expertise as reusable, versioned skills behind approval gates. In Kylon the case context stays in the room, the procedure is written down as a Skill and kept in memory, a Workflow repeats it, and any decision that changes something comes back to a person for approval.
- Vendors are calling this a control plane or a harness. Is that the same thing?
- It is the same set of questions at a larger scale. A harness bundles context, action, governance, security and model choice into one layer for a whole enterprise. Kylon answers the workspace-level part of it: which rooms an agent belongs to, which accounts it acts through, which actions wait for a person, and what the run history shows afterwards. It is not an identity provider and does not federate agent identity with one.
- Does governance slow the work down?
- It changes where the wait is. An agent can read, research and prepare without asking, and the pause happens at the point where something leaves the workspace or changes a record. For most teams that is one review instead of doing the work by hand.
Trust is a property of the workspace, not of the prompt.
Give an agent the rooms and accounts its job needs, keep the approval next to the evidence, and let the run history answer the question people ask later.