Once an AI agent can write to business software, its permission system becomes as important as its model. The model proposes an action. Connections, account roles and approval rules decide whether that action reaches the real world.
This is why the next layer of competition will not be limited to model quality. Agent platforms are also competing to become the place where organisations connect accounts and decide what software may do on their behalf. The technical layers behind that claim are mapped in what sits underneath an AI agent.
A connection button hides several decisions
“Connect” looks like one action in a product interface. Behind it sit several separate choices: which account is being used, which organisation is selected, what scopes are granted, how long access lasts and who can revoke it.
Those details are easy to ignore during a demonstration. They become obvious when an employee changes role, a contractor leaves or the agent reaches the wrong project.
Permissions need to describe actions
Traditional software roles are often broad: viewer, editor and administrator. Agents need more precise boundaries because they can combine actions quickly and repeat them at scale.
An operator may be comfortable allowing an agent to read support tickets and prepare replies. Sending those replies, issuing refunds and changing account access are separate decisions. A platform that represents them as separate permissions gives the business a usable control surface.
The connector layer creates leverage
The platform that maintains trusted connections to email, payments, documents, analytics and developer tools occupies a powerful position. It can decide which services are easy to reach, what permission choices are presented and how activity is recorded.
Open connection standards can reduce the cost of building each integration. The current Model Context Protocol architecture separates hosts, clients and servers, creating clearer boundaries between the AI application and connected services. The platform still has to choose sensible defaults and enforce the user’s decision.
Approval is an infrastructure feature
Human review is often discussed as a general principle. In working software it has to be implemented: an action pauses, a person receives enough context, the approval is recorded and the system resumes without repeating the action.
That machinery is not glamorous, but it is difficult to add after an autonomous workflow has already been designed. The NIST AI Risk Management Framework treats roles, responsibilities and oversight as operating concerns rather than statements of intent. Agent platforms will need to turn those concerns into ordinary product controls.
Revocation must work faster than automation
Every connection needs a clear owner and a reliable way to stop it. Removing a user from the visible workspace is not enough if background jobs, copied tokens or service accounts remain active.
Useful platforms will show where an agent has access, when each connection was last used and what will stop working if it is revoked. That record becomes part of the organisation’s operating inventory.
The durable product is the control layer
Models will continue to change. Businesses may use several of them for different jobs. The harder layer to replace is the one holding approved connections, policy decisions, execution history and recovery controls.
That does not guarantee today’s agent platforms will become permanent infrastructure. It explains where their staying power could come from: ownership of the boundary between a generated decision and an authorised action. Operators choosing the actual scopes should use the practical AI-agent permission framework.