How do I control what AI agents can access, change and send?

AI agents need three layers of control: what data they can read, what changes they can make, and approval for anything that goes outward. Control methods include permissions per person, review gates before sending, audit logs of all actions, and the ability to revoke access instantly.

How do I control what AI agents can access, change and send?

AI agents need three layers of control: what data they can read, what changes they can make, and approval for anything that goes outward. Control methods include permissions per person, review gates before sending, audit logs of all actions, and the ability to revoke access instantly.

Three dimensions of control

Access control: Who on your team can use which agents, and what data can they reach. An agent that helps with customer replies needs access to message history and customer information, but not to payroll. A content agent needs access to articles and brand guidelines, but not to contracts or strategy documents. Most platforms control this at the person level—a salesperson gets sales tools but not ops dashboards. Better platforms also control what data the agent itself can see, separate from what the person can see.

Change control: What an agent is allowed to modify. An agent that drafts customer replies should not erase old messages. An agent that writes social media should not change pricing. The strictest approach: agents can only read and draft, never modify or send without a person's approval. The most permissive: an agent has write access to certain systems with no gates. Most teams find the middle ground: agents can change some things (a draft response, metadata tags) but wait for approval on anything consequential (sending, publishing, charging money, deleting).

Send control: Approval gates for anything that leaves the company. A customer reply should go out only if the owner or designated person approves it. A published article should pass a check for brand voice, accuracy, and links. An API request should be logged and possibly reviewed. The strictest: nothing goes out without a person's explicit OK. The most permissive: some channels can auto-approve if they pass certain checks (the reply is relatively brief and the tone is neutral). The best systems let you set different rules per channel or per kind of work.

How to control agents in practice

Separation of agent access from human access: The best approach is one way: allow agents to read what they need (business records, customer messages, prior responses) but require human approval for writes. This means an agent can draft a reply from the full message thread without being able to send it. It reads your customer data without being able to erase it. The agent and the person are separate—the person sees what the agent found, decides what to do.

Access revocation: A good system revokes access in seconds, not days. If a person leaves, if an agent misbehaves, or if you change your mind about what it can reach, it should be off on the next click, without asking a database administrator or waiting for a cron job.

Audit logs: Everything an agent does should be logged—what it read, what it drafted, what a person changed or approved. That log is not just for compliance: it is how you know what happened when something is wrong. A reply went out with a typo, or an agent drafted something unsafe. The audit log shows you the draft, who approved it, and when. It shows you every person who could have changed something.

Roles and permissions: Different roles need different access. A manager might approve customer replies and see the audit log, but not change the brand guidelines. A content creator drafts articles but does not send them. An admin sets up integrations but doesn't work with customers. A system with no roles makes one person the bottleneck; a system with flexible roles scales work across the team.

Shared business context: If every agent and every person share the same business context (brand voice, customer history, pricing rules), they work from the same information and the person reviewing an agent's work can approve it faster. This matters because approval gates are slow if the approver has to re-read everything the agent saw.

Ownbox approach

Ownbox builds containment into its design. AI agents on an Ownbox work inside the box, on your records, behind a locked door. They can read and draft, but a person decides what goes out.

Access control on Ownbox: Everyone signs in with their own login, and the owner decides who can use what. The owner invites people to the Ownbox, assigns them roles and permissions, and revokes access in one click. An agent like the Inbox Machine or SEO Machine connects to the owner's data through the owner's own AI account—the agent does not have a separate login and does not connect directly to business systems. Instead, it reads through a secure door that only works from inside the Ownbox.

Change control on Ownbox: Every action an AI agent wants to do on an Ownbox waits for a person's OK, and every action is logged. The Inbox Machine drafts customer replies but does not send them—a draft waits to be approved, edited or skipped, from the dashboard or the phone. The SEO Machine writes articles but does not publish them—before publishing, a hard check blocks words the business never uses, competitor names and any number it has not approved. If the owner wants to let a channel (such as DMs) answer on its own, they can, and can switch it off again at any time.

Send control on Ownbox: The owner approves what goes out. The approval can be instant if the owner is using the dashboard when a draft arrives, or it can be batched—read all the drafts from the morning, approve the safe ones together, and skip the ones that need a reply first. Nothing the Inbox Machine writes goes out unless the owner has allowed it. The SEO Machine publishes to the owner's own website, which the owner owns and controls.

Visibility on Ownbox: Pro adds an audit log. Every setting shows who changed it, so the owner knows who gave an agent permission to do something. The Morning Review shows what happened overnight and what needs attention.

Revoking on Ownbox: A revoked person is out on their next click. If an agent misbehaves—drafting unsafe replies, reading the wrong data—the owner can turn it off instantly from the dashboard.

Ownership on Ownbox: The owner's AI runs on the owner's account. The data and the code are the owner's. An Ownbox can be moved to the owner's own DigitalOcean account whenever the owner wants, and it runs there without Ownbox, so the owner never loses control.

What to look for in an AI agent system

• Approval before send: Are drafts reviewed and approved by a person before they go out, or do they send automatically?
• Permissions per person: Can the owner assign different levels of access to different team members, or is it all-or-nothing?
• Audit log: Is there a record of what the agent did, what a person approved, and who made changes?
• Revocation speed: Can access be removed in seconds, or is it a process?
• Separation: Can an agent read the data without being able to send on its own?
• Ownership of data: Who owns the data and the AI account the agent uses?

Next step

Ownbox is built for teams that want AI agents working contained, sharing the same business context, with control over what they access and what goes out. Start at Ownbox.io.