Every agent gets an owner, a scope, and an off switch.
Agent usage policy and guardrails decide who owns each agent, what it may touch, what it may spend, how it is stopped, and what record it leaves. Atlas Bench designs and enforces them for Rovo agents, Forge apps, and MCP-connected tools, using the permissions, budgets, and audit logs the platform already has.
Ownership, scope, cost governance, off switches, and audit trails for Rovo agents, Forge apps, and MCP-connected tools, enforced by the platform rather than described in a policy nobody reads.
The problem
Agents arrive one team at a time. An agent gets access because a person granted it, runs against a budget nobody is tracking, and produces work that enters the same queues as everything else. When something goes wrong, the first discovery is usually that nobody knows who owns it or how to switch it off.
The questions that follow are always the same: who owns it, what can it touch, how much does it cost, and how do we prove any of that to an auditor. A policy document answers none of them on its own. Permissions, budgets, suspension paths, and audit logs configured in the platform answer all four.
What the work is
Agent inventory and ownership
Every Rovo agent, Agent in Jira, Forge app, and MCP connection running today, the identity each one acts as, and a named owner for each, or its place on the unowned list.
Scope and permissions
What each agent may read and change, expressed as the identity it runs as and the groups that identity holds, so scope is enforced by the platform rather than stated in a document.
Usage policy
What may be connected, by whom, which work may be delegated to an agent, and what must escalate to a person, written in terms the platform can enforce and a reviewer can check.
Cost governance
Consumption attributed to each agent and team, with budgets and alerts, so spend is owned and reviewed rather than discovered at renewal.
Off switches and escalation
A tested way to suspend any agent or connection, who is allowed to use it, and what happens to work already in flight when it is used.
Audit trails
A retained record of what each agent did, as which identity, and on whose authority, kept where an auditor or an incident review can read it.
Agent review cycle
Agents on the same review cycle as people: owner confirmed, scope re-approved, spend checked, and agents that have fallen out of use retired.
How it runs
-
Inventory
2 to 3 weeksAn export-driven discovery of every agent, app, and connection, the identities they run as, and what each can reach today.
-
Policy and design
2 to 3 weeksThe scope model, the usage policy, the cost model, and the off-switch procedure, approved by the owners before anything changes.
-
Enforcement
3 to 5 weeksPermissions narrowed, budgets and alerts configured, audit retention set, and suspension paths built, highest-risk agents first. Every off switch is tested before handover.
-
First review
2 weeksThe runbook and administrator training handed over, and the first agent review run with your team rather than for them.
What you get
- An inventory of every agent, app, and connection, with its owner and the identity it acts as
- A scope model for each class of agent, applied as permissions rather than guidance
- A written usage policy covering connection, delegation, and escalation
- Budgets and alerts attributing agent consumption to owners and teams
- A tested off-switch procedure for every agent and connection in scope
- Audit trail configuration with retention agreed against your audit requirements
- An agent review procedure, with the first cycle run alongside your team
- As-built documentation and administrator training
Proof
Of CISOs say they worry about agents and assistants being granted excessive access.
Okta Global CISO Insights, 2026.
Of organizations are confident their identity and access management can handle agents.
Cloud Security Alliance and Strata, 2026.