AI Agent Permissions: Can Agents Be Trusted With Company Systems?

AI agents can be trusted with company systems when their access is designed, not inherited. Give each agent the least access its job needs: read only by default, write access one tool and one action at a time, and a person approving anything that sends, publishes or spends. An API key that can do everything is not a safety layer.

This is general information, not legal advice.

Can AI agents be trusted with company systems?

Yes, within limits that match the job. The question is not whether an agent is trustworthy in general, but what it can reach and what it can change. An agent that can only read a sales report is low risk. An agent that can edit every CRM record and send email from your domain is not.

The risk is real and measurable. According to IBM's 2025 Cost of a Data Breach report, 13% of organisations studied reported breaches of AI models or applications. Of those, 97% lacked proper AI access controls.

Trust, in practice, is designed into three things: what the agent can read, what it can do, and what requires a person's approval.

What is least privilege for AI agents?

Least privilege is a long-standing security principle: give a user or process only the access needed to do its task. NIST, the US standards body, defines it as restricting access to the minimum necessary. For AI agents, it means scoping each agent's reach to its specific job.

The principle is old; agents make it urgent. A person with broad access uses a little of it each day, carefully. An agent with broad access might use all of it in seconds if its instructions are misread or manipulated.

A common shortcut makes this worse: giving an agent the same access as the employee who set it up. That person's full access is usually far broader than the agent's single task needs.

How should access be granted to AI agents?

Grant access in three layers. For reading, allow only the data sources the job needs. Acting starts with no write access, added per tool and per action. Approving means you require a named person for anything that sends, publishes, spends or changes many records.

Two refinements help. First, prefer actions that are reversible: a paused campaign or a draft post can be fixed before anyone sees it. Second, for tools where the key allows everything, put an allow list between the agent and the tool, so only named actions are possible and anything else is refused.

Why is an API key not a safety layer?

Because many keys grant far more than any one job needs. A single key might allow reading, writing, sending, publishing and deleting, and some tools offer no read-only option at all. Sometimes the only thing between an agent and a destructive action is its instructions. Then safety depends on those instructions never being wrong.

That is why access and permission need to be treated separately. Access is what the key technically allows. Permission is what the business has decided the agent may do. Closing the gap takes three things. Each tool needs written rules, the riskiest need code that refuses anything outside an allow list, and a person takes the final step.

Official guidance points the same way. According to the National AI Centre's Guidance for AI Adoption, the six essential practices include deciding who is accountable and maintaining human control. The guide to access versus permission goes deeper.

How do you review AI agent access?

List every agent with what it can read, what it can change and who approves its output. Then review that list regularly. Remove access an agent no longer needs, check for permissions that crept in with new integrations, and record who approved each grant. Treat agents like new staff whose access is reviewed.

Permission creep is the quiet risk. Each new integration seems reasonable on its own; together they add up to an agent that can do far more than anyone intended. A quarterly review catches it.

Privacy rules apply as well. Australia's privacy regulator says the Privacy Act applies to all uses of AI involving personal information, so an agent that reads customer data needs the same care as a person who does.

Approval design is covered in the guide to human in the loop.

Skein builds every Company OS connection read only first, with write access granted one tool and one action at a time and named approvers for anything that goes out; the shared knowledge layer page explains the permissions. That suits a business connecting agents to its CRM, inbox or website. A team using AI only for drafting in a chat window has much less to configure.

Frequently asked questions

How much access should an AI agent have?

Only what its specific job needs. Start with read access to the relevant data, add write access one tool and one action at a time where genuinely required, and keep a person approving anything that sends, publishes, spends or changes many records. Review access regularly.

What is least privilege for AI?

Least privilege means restricting an AI agent's access to the minimum necessary for its task, as NIST defines the principle for users and processes. In practice, an agent reads only the data its job needs and can take only the specific actions it has been granted.

Can an AI agent send emails or change CRM records?

It can if it has been given that access, which is why access should be granted carefully. A safer pattern is for the agent to create drafts or paused items, with a person reviewing and sending. Bulk changes to records should always need human approval.

Why aren't API keys enough to control AI agents?

Many API keys allow far more than a job needs, including writing, sending and deleting, and some tools have no read-only option. Relying on the agent's instructions alone is fragile. Written rules, allow lists for risky tools and human approval close the gap between access and permission.

How often should AI agent permissions be reviewed?

At least quarterly, and whenever an agent gets a new integration or its job changes. List what each agent can read, change and send, remove access it no longer needs, check for permissions that crept in, and record who approved each grant.

Related reading