An AI chat window answers questions. An AI agent does things: it creates tasks, updates records, drafts and sends messages, and calls other tools. The moment software can act on your behalf, three questions follow it into every security review. What is it allowed to touch? Who said yes? What exactly did it do? Governance is the set of answers to those three questions, written down and enforced by the product rather than by good intentions.
This guide explains the parts of a sound governance setup, the mistakes that make one decorative, and how the controls work in Atlas, since that is the system we can describe from the inside.
The four parts of agent governance
1. Scope. An agent should start with the smallest set of permissions that lets it do its job, and it should never hold more access than the person who switched it on. In practice this means scoping by action (read a deal, but not delete one), by area (the CRM, but not payroll), and by data (one project, not every project). If an agent can do anything its owner can do, you have not scoped it, you have cloned the owner.
2. Approval. Some actions are reversible and cheap. Others are not: sending an email to a customer, changing a contract, moving money, deleting records. Good governance names the actions that need a person to approve them first, and the agent waits until someone does. The approval should show exactly what the agent intends to do, with the real values, not a vague summary.
3. Limits. Even a well-scoped agent can loop, retry, or run far more often than anyone expected. Limits put a ceiling on that: how many runs, how many actions per run, and how much it may spend on model calls. A limit turns a runaway mistake into a stopped one.
4. Record. Every action an agent takes should land in the same audit log as human actions, attributed to the agent and to the person who owns it, with a timestamp and the values that changed. If an agent can act without leaving a record, nothing else in this list can be checked.
Mistakes that make governance decorative
The most common mistake is approval fatigue. If an agent asks permission for everything, people stop reading the requests and click yes, which is worse than no approval at all because it looks like oversight. Ask for approval on the actions that matter and let the routine ones run.
The second mistake is a separate log. When agent actions live in a different place from human actions, an investigation has to merge two timelines, and the gaps between them are exactly where problems hide. One log, one timeline.
The third mistake is treating a policy document as a control. A page that says agents may not export customer data is a wish. A permission the product enforces is a control. When you evaluate a tool, ask to see the setting, not the policy.
How it works in Atlas
Atlas has an Agent governance area in workspace settings, with four views: the agent teammates and what each may do, the approvals waiting for a decision, what agents remember, and their activity. Each governed agent shows its run count, its pending approvals, its guarded actions, and a spending cap. Guarded actions wait for a person to approve them before the agent runs them, and every action is written to the workspace audit log on the same footing as a human action. Agents work within the scopes you give them, and tools reached through the Atlas MCP server are scoped per tool. You can watch these screens in the Atlas product tour.
Two limits are worth stating plainly. These controls are product features, not a certification, and wrxstack holds no SOC 2 or ISO 27001 report today. And governance is only as good as the scopes you set: an agent given broad access will use broad access.
A short checklist before you switch an agent on
Name the job in one sentence. Give it only the permissions that job needs. List the actions that must wait for approval. Set a run limit and a spending cap. Confirm its actions appear in the audit log by running it once and reading the entry.
What is the difference between an AI assistant and an AI agent?
An assistant answers and drafts, and a person decides what happens next. An agent takes actions itself, such as creating records or sending messages, which is why it needs scopes, approvals, limits, and a record of what it did.
Which agent actions should need approval?
Anything that is hard to undo or leaves the company: sending messages to customers, changing contracts or prices, deleting records, exporting data, and spending money. Routine, reversible work can run without approval.
Does Atlas let me approve agent actions before they run?
Yes. Guarded actions wait in an approvals queue in the Agent governance settings until a person approves or rejects them, and every action an agent takes is written to the audit log.
Is agent governance the same as compliance?
No. Governance is the set of controls that make agent actions safe and checkable. Compliance is whether an auditor has examined your controls against a standard. Good governance makes an audit easier, but it is not a certificate.
Where this lives in wrxstack: security at wrxstack and Atlas for enterprise.