Your next IT user might not be human

Businesses are used to managing access for people. A new employee gets an account, a role, a device and a set of permissions. When they change jobs or leave, access should be reviewed or removed.

AI agents introduce another category: software capable of using business systems on somebody's behalf. An agent might read a calendar, search a CRM, summarise documents, update a ticket or start a workflow. It may not look like a user sitting at a desk, but it can still act with business authority.

The useful security response is not futuristic language or a blanket ban. It is to apply familiar access principles carefully, while recognising that software can act at much greater speed and scale than a person.

What is an AI agent in security terms?

An AI assistant that only answers a question from information a person has already supplied is different from an agent that can retrieve information, call an API or make a change in a business system.

The more independently an AI system can find information, decide what to do and take action, the more important its identity, permissions and audit trail become. The word “agent” should prompt practical questions:

• Which account, application identity or connection does it use?
• What information can it read?
• What can it change, send, export or delete?
• Who approved that access and who owns it now?
• How would the business see what it did?
• How quickly could access be revoked?

Use the same principles as privileged access

AI access does not need its own mysterious security philosophy. It needs the same disciplined thinking used for administrators, service accounts, integrations and other privileged connections.

Least privilege

Give an agent the smallest useful permission set. If it needs to read a calendar, that does not mean it should be able to change everything in the tenant. If it needs CRM information, that does not mean it needs unrestricted ability to export or delete CRM data.

Separate identities where technically appropriate

Do not hide every automated action behind a person's ordinary account if the platform can support a named application identity, delegated connection or other separation. The right pattern depends on the product, but the goal is clear ownership and a useful audit trail rather than an unexplainable shared credential.

Avoid unnecessary administrator access

“It needs to troubleshoot” is not the same as “it needs to be a domain administrator.” Administrative access can expose far more data and create far more possible impact than the task requires. Start with the task, then work out the minimum permission that can complete it.

Limit data and actions

Restrict both what the agent can see and what it can do. A support agent might need to read a ticket and suggest a response but not send the message. A finance workflow might read invoice information but not have authority to make payments. A document assistant might search a project folder but not every confidential folder in the business.

Require approval for sensitive operations

Actions such as external sharing, deletion, payment, access changes, bulk export or sending an important customer communication may deserve a human approval step. Automation can prepare the action without being allowed to complete the most consequential part on its own.

Log, monitor and review

Access is not controlled simply because somebody approved it once. The business should be able to see meaningful activity, investigate unusual behaviour and review whether the connection is still needed. Monitoring should focus on outcomes and risk, not create a false promise that every AI action can be understood perfectly.

Manage credentials and revoke quickly

API keys, application secrets, delegated tokens and service accounts are credentials. Store them appropriately, limit their lifetime where the platform allows it, know who owns them and rotate or revoke them when the purpose changes. A connection that cannot be found or disabled quickly is difficult to govern.

Speed and scale change the risk

A person may make one mistake in one system. An agent can repeat a mistaken instruction across hundreds of records, follow a flawed rule overnight or expose a large set of documents before anybody notices.

This does not make every agent dangerous. It makes scope, guardrails and monitoring more important. The question is not only “Could this action happen?” It is also “How many times could it happen before a human sees it, and how difficult would it be to undo?”

A practical review for a small business

Start with an inventory rather than a procurement exercise. Record the AI tools, assistants, automations and integrations already in use, including those introduced by individual teams.

• What system does the agent connect to?
• Which identity or credential does it use?
• What data can it read?
• What actions can it take?
• Are sensitive actions subject to approval?
• What logs or notifications exist?
• Who reviews the connection and removes it when it is no longer needed?

For Microsoft 365, this belongs alongside ordinary identity, privileged access, sharing and application-consent reviews. A Microsoft 365 Security Baseline Review can provide a structured look at those controls. For a wider view of systems and dependencies, an IT roadmap can help distinguish useful automation from unmanaged access.

AI access is part of Zero Trust, not a separate exception

Zero Trust is often reduced to a slogan. In practical terms, it means not granting access simply because a connection is inside a trusted environment or associated with a familiar product. Verify the identity, limit the scope, make the decision appropriate to the risk and keep checking that it still makes sense.

That applies to an AI agent just as it applies to a person, administrator, supplier or integration. The technology may be new; the accountability should not be.

Frequently Asked Questions

Does every AI assistant need its own user account?

Not necessarily. The right identity pattern depends on the platform and the task. The important points are that access has a clear owner, permissions are limited, activity can be understood and the connection can be revoked. A shared or hidden credential makes those controls harder.

Should businesses ban AI agents?

A blanket ban may be disproportionate and difficult to enforce. A better starting point is to identify which tools are being used, what business data they can reach and which actions require approval. Higher-risk uses may need tighter controls or may not be appropriate.

What is the most important first step?

Find out what is already connected. An inventory of AI tools, applications, permissions, owners and approval paths is more useful than assuming that an organisation-wide policy has prevented every unsanctioned connection.

The Altitude IT view

AI agents should be treated like any other privileged access: verify it, limit it and monitor it. Start with the business task, not the product name. If the task does not require broad access, the agent should not receive broad access simply because that is the quickest setup.

Businesses that need help mapping identities, permissions, applications and practical controls can start with independent technology advice or a focused security assurance review.

Sources and Further Reading

• National Cyber Security Centre: Zero trust architecture
• Microsoft Learn: Zero Trust identity and access