Your AI agent is not an employee. Do not lend it the keys to the company

An AI assistant answers.

An AI agent acts.

It can read an email, find the customer in the CRM, consult documents, create a ticket, update a status, prepare a response and, if allowed, send it.

That move from reading to doing changes the question.

It is no longer enough to test whether the agent understands the task. You must decide which identity it uses, what it can see, which tools it can call, which actions require approval and how it will be stopped if it goes off course.

The "digital employee" comparison may explain the idea. It is dangerous when used to design access.

Do not lend an agent a person's password. Do not give it general access just to make the demo work. Do not rely on a prompt saying it will only do the right thing.

An agent needs its own keys—and only those its job requires.

This week's signal is not hypothetical

On 16 July, Microsoft published specific guidance on least privilege for AI agents. Its core recommendation is to treat every agent as a first-class identity: a dedicated identity, a human owner, an explicit purpose, task-scoped permissions, approved tools and fast revocation.

The same day, VentureBeat published a directional survey of 107 organisations with more than 100 employees that already use agents. Fifty-four per cent reported a confirmed incident or near miss; 69% had credential sharing somewhere in their agent fleet; and only 30% isolated their highest-risk agents.

The sample is small, self-selected and weighted toward the mid-market. It does not prove those percentages represent every business. It does expose a pattern worth taking seriously: agent capability is moving faster than identity and isolation controls.

For an SME, the lesson is not to buy an enormous security platform. It is simpler:

do not connect an agent to real work through a borrowed identity and permissions nobody designed.

A borrowed password erases three boundaries

Imagine an agent preparing customer responses under a team member's account. At first, it only reads email. Then it needs CRM access, ticket creation and status updates. Each extension looks small.

After a few months, the same identity can reach customers, documents, conversations and internal operations.

Three boundaries have disappeared:

Authorship: the log says the person acted even when the agent did.
Scope: the agent inherits everything that account can do, not only what the task needs.
Revocation: stopping the agent may require changing credentials that a person or several integrations still need.

That makes errors harder to investigate, increases the possible impact and turns a quick pilot into operational debt.

Six controls before granting access

You do not need a multinational architecture on day one. You do need precise answers to six questions.

1. Does it have its own identity and owner?

Each production agent should have a separate identity, a recognisable name, a written purpose and a person responsible for approving changes and handling incidents.

The identity should remain stable for lifecycle management. Elevated permissions should be temporary: short access for a specific task, not a permanent master key.

2. Does it have the minimum permission for the task?

"CRM access" is not precise enough.

Can it read every record or only those assigned to one team? Can it create a note, change an address, export data, delete, or alter pricing?

Permissions should be designed around task, data and action. Read and write should be separate. Export, delete, privilege changes and financial commitments should remain blocked or require temporary elevation.

3. Can it use any tool or only an allowlist?

An agent should not discover freely which connectors to use in production. There should be an explicit list of permitted tools and actions.

This matters because an agent can chain individually harmless capabilities. Reading email, consulting files and calling an external service can collectively create a data-exfiltration path nobody assessed as a complete workflow.

Microsoft uses a useful phrase: beyond least privilege, apply least agency. Limit not only the data an agent can touch, but how much it may decide and chain on its own.

4. Where is human approval?

The most practical boundary for many SMEs remains:

prepare, yes; commit the company, not without approval.

An agent can prepare a draft, classify a request, assemble evidence or propose an update. Sending a sensitive message, changing critical data, accepting terms, applying a discount, approving a payment, deleting information or affecting a person requires an explicit decision.

The approval screen must show what will happen, which data is involved and which change will be made.

5. Do the logs explain what actually happened?

Saving only the model's final answer is not traceability.

A useful log must answer: which agent acted, under which identity and permission, on whose behalf, which tool it called, which resource it touched, what changed, which approval it received and what result followed.

Without that chain, you have recorded activity, but not a reliable story for correcting an error or investigating an incident.

6. Can you really stop it?

An untested kill switch is a hope, not a control.

The business must be able to disable the identity, invalidate tokens, revoke credentials and block tools without dismantling half the operation. It also needs rollback or compensating actions for common failures such as mass-created tickets, incorrect statuses or unwanted updates.

Testing the stop path before production is as important as testing whether the agent completes the task.

Example: a customer inbox connected to the CRM

A quick design says: "let the agent read the inbox, open the CRM and reply".

A controlled design looks different:

The agent has its own identity and owner.
It reads one inbox and only the necessary CRM fields.
It may search, summarise, classify and create a draft.
It may not export customers, change commercial terms or delete records.
A person reviews and sends sensitive responses.
Each query, source, draft, review and action is correlated.
A tested switch invalidates its access.

The second version takes longer to design. It is much faster to govern when the agent fails, the workflow changes or someone asks who did what.

The expensive mistake: open everything during the pilot

Many businesses plan to reduce permissions "once the pilot works".

That moment rarely arrives.

The pilot becomes useful. Another system is connected. An exception appears. The scope expands. The shared account becomes a dependency. Narrowing permissions later means discovering an architecture that was never documented.

Limits are not the final security phase. They are part of the functional design because they force the company to define the work being automated.

The 30-minute checklist before connecting an agent

Does it have a separate identity and a named owner?
Can its purpose be written in one concrete sentence?
Which exact data, resources and actions does it need?
Which tools are allowed and denied?
What can it prepare without approval?
Which financial, external, sensitive or destructive actions require approval?
Can the logs reconstruct every step?
Have identity, token and tool revocation been tested?

If an answer is vague, the agent does not need more autonomy yet. It needs better design.

Conclusion: autonomy with its own keys

AI agents can create real value because they connect information and actions across several systems. The same capability expands the impact of an error.

The answer is not to keep AI locked inside a chat. Give it a dedicated identity, a limited job, known tools, a human boundary, useful logs and an emergency exit.

Last week we explained why organisations should make an inventory before deploying agents.

The next step is deciding which keys each one receives.

Your AI agent is not an employee. Do not lend it the keys to the company.