How do you give an AI agent access to your business systems?
You give an AI agent access one system at a time, scoped to the specific jobs it is contracted to run, never as a blanket admin account. Three things make that access safe rather than reckless: least privilege credentials issued per system, approval gates on any action that leaves the company or changes money or data, and a reviewable log of every action the agent took. An agent with all three can be supervised. An agent missing any one of them cannot.
Grant access per system, never as one master key
The fastest way to connect an agent is to hand it an existing admin login. It is also the choice teams regret first. A shared admin account merges the agent's actions with a person's actions in the same audit stream, so when something looks wrong later there is no way to attribute it. Worse, it grants the agent every permission that account carries, including the ones its contracted jobs never touch.
Issue a named credential per system instead. The inbox gets one. The CRM gets one. The reporting source gets one. Each is scoped to the permissions the contracted job actually requires, which in most cases is read access plus the ability to write to one specific place. This takes an extra hour at setup and it is the difference between access you can govern and access you can only hope about.
Decide in advance what stops for a human
Access is only half the question. The other half is what the agent may do with it unsupervised. The practical line is consequence and reversibility. If an action is internal and reversible, let the agent run it. If an action reaches a customer, moves money or destroys a record, it should pause and wait for a person.
That line should be written down before the first run, not negotiated after an incident. Teams that set it early tend to expand the agent's autonomy over time as the record builds confidence. Teams that skip it tend to react to one bad outcome by switching the whole thing off.
Require a readable record of every action
Supervision depends on evidence. An agent that reports success without showing its work cannot be checked, and an unverifiable agent is indistinguishable from a broken one until a client notices. Every run should produce a record showing what ran, which systems it touched, what changed and what it cost, and that record should survive the conversation it was created in.
For the first several runs of any new job, compare that record against the system of record itself. The agent's self report is a claim. The CRM, the inbox or the ledger is the evidence. Once the two agree consistently, the spot checks can relax.
Keep revocation in your own hands
Ask one question before any credential is issued: if this goes wrong at 9pm on a Friday, can we end the agent's access ourselves, in the system, without contacting the vendor? If the answer is no, the architecture is wrong regardless of how good the agent is. Per system credentials make the answer yes by default, because disabling the credential in the system ends the access immediately.
What this looks like with Steward
Steward is a managed AI agent, so the operating burden sits with the vendor while the access decisions stay with the customer. Access is granted per system and scoped to the skills the plan covers, which is why Steward prices by skill count rather than by seat: the plan and the scope are the same conversation. Consequential actions hold for approval, and every run returns a receipt. Published pricing is 500 dollars per month for one skill, 1500 for up to three and 2500 for up to five.
Related reading: what a managed AI agent is, why the audit trail matters, and what this looks like on a small team. More writing on the Steward blog, or read who operates Steward.
Frequently asked questions
Should an AI agent get an admin account or its own limited account?
Its own limited account, always. A shared admin login makes it impossible to tell afterward whether a change came from the agent or a person, which destroys the audit trail you need to supervise it. Issue the agent a named service account or API credential per system, scoped to the permissions its contracted jobs require and nothing beyond them.
Which systems should an AI agent be connected to first?
Start with the system where the recurring work already lives and where a mistake is visible and reversible. Reporting sources, shared inboxes and spreadsheets are common first connections because the output can be checked before anyone acts on it. Billing systems, payment rails and anything that deletes records should come later, after the approval gates have been exercised on lower stakes work.
What actions should an AI agent never take without approval?
Anything that leaves the organization, spends money, or destroys data. Sending external email, publishing to a public channel, issuing a refund, posting a transaction and deleting records all belong behind a human approval step. Reads, drafts, internal reports and scheduled analysis can run autonomously because an error in them is caught before it reaches anyone outside the team.
How do you revoke an AI agent access if something goes wrong?
The same way you revoke a departing employee, which is why per system credentials matter. Disable the agent credential in the system itself and the access ends immediately and independently of the vendor. If revoking the agent requires a support ticket to the vendor rather than a toggle you control, the access was never really yours to govern.
Does an AI agent need access to everything to be useful?
No. Usefulness comes from depth in a few systems, not breadth across all of them. An agent that reliably handles one recurring job end to end in two systems delivers more than an agent with read access to twelve systems and no contracted job in any of them. Scope the jobs first and let the access list follow from the jobs.
How do you verify an AI agent only did what it was supposed to do?
Read the run record. Every action the agent takes should produce an entry showing what ran, what it touched, what changed and what it cost, and that record should be readable after the fact rather than only in the moment. Spot check the records against the system of record itself for the first several runs of a new job, because a self report is a claim and the system of record is evidence.