Room 4, 8th Floor George Silundika Avenue Harare
View My Work
Your Next Employee May Be an AI Agent. But Who Gave It Permission?
Home » AI  »  Your Next Employee May Be an AI Agent. But Who Gave It Permission?

Your Next Employee May Be an AI Agent. But Who Gave It Permission?

Artificial intelligence is undergoing an important transition.

For the past few years, most organisations have interacted with AI as an assistant. We ask it a question, give it a document to summarise, request an analysis or ask it to draft an email.

The human remains firmly in control of what happens next.

That is beginning to change.

The emergence of agentic AI means AI systems can increasingly perform tasks rather than simply recommend what a person should do. An AI agent may be able to read emails, retrieve information from databases, interact with business applications, update records, call APIs and execute workflows.

This offers enormous opportunities for productivity.

It also introduces a cybersecurity question that organisations need to start taking seriously:

If an AI agent can act on behalf of an employee or organisation, exactly what should it be allowed to do?

This could become one of the defining AI security questions of the next few years.

From AI Assistants to AI Agents

Consider the difference between asking an AI assistant:

"Please draft a response to this customer complaint."

and instructing an AI agent:

"Resolve this customer complaint."

The first task produces text for a human to review.

The second could involve several actions. The agent might read the customer's email, search the CRM, retrieve previous interactions, check the customer's account, determine an appropriate response, update the CRM and send an email.

Potentially, it could do all this without a person performing each individual step.

The productivity potential is obvious.

But so is the security implication.

The AI now needs access.

And access creates risk.

AI Agents Are Becoming Digital Workers

Think about what happens when a new employee joins an organisation.

The employee normally receives a username and password. They are given access to certain applications, folders and databases depending on their role.

An HR officer should not automatically have administrator access to the accounting system.

A marketing officer does not need unrestricted access to payroll records.

A junior accountant should not necessarily have authority to approve a major payment.

These restrictions exist for good reason.

Organisations apply principles such as least privilege, segregation of duties and role-based access control to reduce risk.

AI agents should not be treated differently simply because they are software.

If an organisation deploys an AI agent to perform work, an important question becomes:

What is the digital identity of that agent?

Closely followed by:

What permissions does that identity have?

The Problem of Excessive Agency

One of the attractions of agentic AI is autonomy.

The more an agent can do independently, the more time it potentially saves employees.

But there is a trade-off.

Giving an AI agent access to email, customer databases, financial systems, cloud storage and business applications creates a very different risk profile from giving employees access to a standalone chatbot.

Imagine an AI procurement agent.

To perform its role effectively, it might be allowed to:

  • read supplier emails;
  • access procurement records;
  • retrieve quotations;
  • update supplier information;
  • prepare purchase orders;
  • communicate with suppliers; and
  • initiate approval workflows.

Now imagine that the agent misinterprets an instruction, is manipulated by malicious content or operates outside its intended objective.

The problem is no longer simply that the AI produces an incorrect answer.

The AI may be able to take an incorrect action.

That distinction matters.

Prompt Injection Becomes More Dangerous When AI Can Act

Prompt injection has already become an important concern in generative AI security.

In simple terms, an attacker attempts to manipulate an AI system's instructions so that it behaves in an unintended way.

With a conventional chatbot, the consequences may sometimes be limited to an inappropriate or incorrect response.

With an AI agent connected to organisational systems, the consequences could potentially be more serious.

Imagine an AI assistant analysing a supplier document containing malicious instructions hidden within the content.

If the AI can only summarise the document, its ability to cause harm is limited.

But what if the same AI can access internal systems, retrieve confidential information, modify supplier records or send external communications?

The vulnerability may be similar.

The potential impact is completely different.

This is why AI security cannot focus only on securing the model.

Organisations must also secure the environment in which the AI operates.

Least Privilege Must Apply to AI

A fundamental cybersecurity principle is least privilege.

An individual or system should receive only the access required to perform its legitimate function.

That principle should become central to AI deployment.

An AI recruitment agent may need access to job applications but probably does not need access to employee payroll.

An AI customer-service agent may need to retrieve customer information but may not need authority to modify financial records.

An AI finance agent may need to prepare a payment recommendation without having permission to release the payment.

This suggests that organisations should avoid giving AI agents broad permissions merely because doing so makes implementation easier.

The question should not be:

"What systems could this AI use?"

It should be:

"What is the minimum access this AI requires to perform this particular task?"

Not Every AI Decision Should Be Autonomous

There is another important consideration.

Not all organisational actions carry the same level of risk.

Allowing an AI agent to schedule an internal meeting is very different from allowing it to change an employee's salary.

Drafting a purchase order is different from approving a US$100,000 transaction.

Preparing a response to a customer is different from authorising a refund.

Organisations therefore need to establish levels of AI authority.

Low-risk and reversible actions might be suitable for greater automation.

Higher-risk actions may require human review or explicit approval.

Particularly sensitive actions could remain entirely outside the AI agent's authority.

The objective should not necessarily be maximum autonomy.

It should be appropriate autonomy.

AI Agents Need Audit Trails

Suppose an AI agent makes a serious mistake.

Management asks:

What happened?

Can the organisation determine what instruction the agent received?

Can it determine which information the agent accessed?

Can it see which applications or tools were used?

Can it reconstruct the actions that were taken?

Can it identify whether a human approved any critical action?

And can it establish who was ultimately responsible?

If these questions cannot be answered, the organisation has more than a technical problem.

It has a governance and accountability problem.

AI agent activity therefore needs appropriate logging, monitoring and auditability.

The ability to automate work should not mean losing the ability to understand how that work was performed.

The Rise of Non-Human Identities

There is another dimension of the issue that deserves attention.

An organisation might currently have 500 employees and therefore manage approximately 500 employee digital identities.

What happens when the same organisation eventually has hundreds of AI agents?

Some might handle recruitment.

Others might process invoices, monitor inventory, analyse sales, respond to customers, prepare reports or support procurement.

Some may operate continuously.

Others may exist temporarily to perform a specific workflow.

We could therefore see organisations managing substantial populations of non-human digital identities alongside their human employees.

That creates new questions for Identity and Access Management.

Who creates an AI agent's identity?

Who approves its permissions?

How frequently should those permissions be reviewed?

What happens when the agent's responsibilities change?

Who disables the identity when the agent is retired?

Can one AI agent delegate authority to another?

The answers cannot simply be assumed.

They need to become part of AI governance.

AI Governance Must Move Beyond Acceptable Use

Many organisations are currently developing AI policies.

These often address sensible questions such as whether employees may use public generative AI tools, what information may be uploaded and which platforms are approved.

That is an important starting point.

But agentic AI requires governance to go further.

Organisations increasingly need to define:

What can the AI see?

What information can it remember?

Which systems can it access?

Which tools can it use?

What actions can it take?

How much authority can it exercise?

When is human approval mandatory?

How is its activity monitored?

How can its access be revoked?

Who is accountable when something goes wrong?

These are not merely questions for the IT department.

They involve cybersecurity, risk management, internal audit, legal and compliance functions, HR, management and ultimately organisational leadership.

Five Questions to Ask Before Deploying an AI Agent

Before giving an AI agent access to organisational systems, management should be able to answer five basic questions:

1. What is the agent supposed to do?
Its purpose and boundaries should be clearly defined.

2. What information and systems does it genuinely need?
Access should be based on necessity rather than convenience.

3. What actions may it perform without human approval?
Organisations should distinguish between low-risk automation and high-impact decisions.

4. Can we see exactly what it has done?
Appropriate logging, monitoring and audit trails should exist.

5. Who is accountable for the agent?
Every deployed agent should ultimately have a responsible human or organisational owner.

These questions sound straightforward.

In practice, they could become increasingly important as AI agents become embedded in everyday business processes.

The Next Phase of AI Security

The first phase of enterprise generative AI security was largely concerned with what employees were putting into AI.

Confidential information.

Customer data.

Intellectual property.

Sensitive documents.

Those concerns remain important.

But the next phase may increasingly be concerned with what organisations allow AI to get into.

Our email.

Our databases.

Our accounting systems.

Our customer records.

Our workflows.

Our decision-making processes.

And eventually, perhaps, significant parts of our organisational infrastructure.

That means AI security is becoming closely connected to identity, access control, authorisation, monitoring and accountability.

A Question for Every Organisation

AI agents could become extremely valuable digital workers.

They may help organisations automate repetitive activities, improve responsiveness and allow employees to concentrate on higher-value work.

But we should remember something cybersecurity professionals have understood for decades:

Capability without appropriate control creates risk.

The question organisations should therefore ask is no longer simply:

"How can we use AI?"

It is increasingly:

"How much authority are we prepared to give AI, and what controls must exist before we give it that authority?"

Because an AI system that can talk presents one type of risk.

An AI system that can access, decide and act presents another.

The future of AI security may depend as much on managing that authority as it does on securing the AI model itself.


What is your organisation doing to control the identities, permissions and authority of AI agents?

#AISecurity #AgenticAI #CyberSecurity #AIGovernance #ArtificialIntelligence #DataSecurity #IdentityManagement #RiskManagement #DigitalTransformation

Leave a Reply

Your email address will not be published. Required fields are marked *