When AI Starts Taking Action: Managing Agent Identities, Permissions and Access

The greatest risk of agentic AI may therefore not be an incorrect answer. It may be an incorrect action carried out perfectly.

With chatbots, security focused mainly on prompts, responses and the information the model could display. An agent adds more links to the chain: enterprise data, identities, connectors, APIs and specific actions. It can update a record, create a file, launch a process or communicate outside the organisation. An assistant becomes an actor, and the way we manage it must reflect that.

1. From Response to Action

Enterprise use of AI can be simplified into three levels. At the first level, AI works with public information. At the second, it receives controlled access to enterprise data and responds within the user’s working context. At the third, it can perform actions across systems.

This is where the risk profile changes: an incorrect or manipulated response can turn into a data change, external communication or the execution of a process.

Data classification, DLP and user permissions remain important, but they are no longer sufficient on their own. An organisation needs to know which identity the agent operates under, which resources it connects to, which tools it is allowed to use, where it can write data and which steps require human approval. It also needs a clearly defined owner, an audit trail, regular reviews and a way to shut the agent down immediately.

From a security perspective, an agent therefore resembles an application or a digital worker more than a chatbot. It does, however, have one distinctive feature: its behaviour is not always fully deterministic. It changes depending on context, the content of its sources and the approach selected by the model.

The controls we already know from IAM, application security and data governance should therefore not be discarded. They need to be consistently extended to agents as well.

2. When Legitimate Functions Combine into a Risky Chain

A good illustration is indirect prompt injection. In this case, the malicious instruction is not contained directly in the user’s question, but in content that the AI processes, such as an email, document, website or form. If the model fails to distinguish content from an instruction, it may attempt to execute it.

For example, ShareLeak, tracked as CVE-2026-21520, demonstrated this principle in Copilot Studio. Malicious content was interpreted as an instruction and, when combined with access to an internal resource and an authorised communication action, created a path for data exfiltration.

The specific vulnerability was fixed and there was no confirmed incident involving customers. The important point is that each individual step could be legitimate, while their combination led to an undesirable outcome.

A similar precedent was EchoLeak, CVE-2025-32711, a research-based zero-click scenario in Microsoft 365 Copilot. This vulnerability was also fixed, and there was no confirmed exploitation in real-world attacks.

Both cases show that relying on prompt filtering alone is not enough. Data, tools, actions and output channels all need to be restricted so that the failure of one layer does not immediately result in data leakage or an irreversible change. SoftwareOne – Qubit clanok 2026…

3. AI Exposes Existing Permission Debt

When preparing customer environments for Copilot and agents, similar findings repeatedly appear: unmanaged permissions in SharePoint and Teams, Anyone links or access granted to large groups, inactive sites without an owner and sensitive documents without consistent classification.

This is not a problem created by AI. It is debt accumulated through migrations, reorganisations and years of everyday sharing.

Enterprise AI operates within a user’s existing permissions; it does not automatically create new access rights. However, it lowers the barrier between a person and information they are technically allowed to open.

In the past, a user needed to know that a document existed, know its name or at least know where it was stored. AI can find it, combine it with other materials and summarise everything in a single interaction.

The risk is therefore not that AI bypasses permissions. The risk is that it “simply” uses permissions that should no longer exist.

Before deploying AI, it is therefore not enough to ask:

“Does the user have access?”

A much more important question is:

“Should they still have access?”

Practical preparation includes creating an inventory of shared and sensitive sites, identifying sites without an active owner, reviewing public and organisation-wide links, removing unnecessary content and introducing clear classification.

Technology can help with visibility and enforcement, but the decision about who should legitimately have access remains with the data owner.

4. The Agent as a New Digital Identity

For users, we take accounts, roles, access policies, auditing and account termination when they leave the organisation for granted.

A production agent requires similar discipline. It is not enough to know who created it. We need to know its purpose, responsible owner and sponsor, the scope of data it can access, permitted connectors and actions, communication channels, risk level and retirement plan.

Microsoft Entra Agent ID is one example of an approach in which agents are managed as non-human identities with their own permissions and lifecycle.

More important than the name of a specific technology, however, is the outcome: an organisation must be able to attribute an action to a specific agent and to the context in which it acted. Its permissions should not remain hidden inside the creator’s personal connection or an undocumented workflow.

Responsibility also cannot be delegated to an undefined “AI team”.

The business owner confirms the purpose and value, the data owner approves the sources, the IT or platform team manages environments and connectors, and the security or compliance team defines boundaries, monitoring and exceptions.

If nobody knows who is supposed to review the agent regularly and who has the authority to shut it down, the agent is not ready for production. SoftwareOne – Qubit clanok 2026…

5. A Practical Framework: Data – Tools – Actions

The principle of least privilege should be applied to agents across three separate layers. One control cannot replace the others.

Layer	Control Question	Examples
DATA	What can the agent see?	SharePoint, OneDrive, Dataverse, CRM, databases, email or external knowledge sources
TOOLS	What tools can it use?	Connectors, APIs, plugins, workflows and services through which it gains additional capabilities
ACTIONS	What can it actually do?	Read, create, modify, delete, communicate externally or initiate a transaction

An agent that only reads from a selected knowledge base has a different risk profile from an agent with access to email and CRM.

Likewise, an agent that can independently send a message or modify a record has a different profile from one that merely prepares a draft for approval.

Risk assessment therefore cannot end with a list of data sources. It must also capture combinations of tools and the potential impact of actions.

6. Not Every Action Should Be Autonomous

Human-in-the-loop does not mean that a person mechanically approves every single step.

If the system presents too many approval requests, control quickly becomes a formality. A more sensible approach is to classify actions by risk and set the level of autonomy accordingly.

Low risk: Searching for information, summarising content or preparing a draft without changing source data. These tasks can generally be autonomous.

Medium risk: Creating a document, updating an internal record or initiating a reversible process. The appropriate level of autonomy depends on data sensitivity, the scope of the change and whether it can be reversed.

High risk: External communication, changing permissions, deleting data, performing a financial operation or interacting with a critical system. These actions should require explicit approval or another deterministic control.

The language model itself should not decide whether a high-risk action requires approval.

The rule must be enforceable outside the model’s reasoning, through permissions, connector policies, workflows, transaction limits or an approval step.

The model may propose the action; the control layer decides whether it is allowed to execute it. SoftwareOne – Qubit clanok 2026…

7. A Lifecycle Instead of One-Time Approval

An agent is not finished on the day it is published.

Sources, connectors, users, instructions and business purposes change. It therefore needs a managed lifecycle similar to an application:

Design → Test → Approve → Publish → Monitor → Review → Retire

Design – Is the purpose clear? Which data and actions are genuinely necessary? Who is the owner and sponsor?

Test – How does the agent behave when it receives incomplete, unexpected or malicious input? Can its actions be reversed?

Approve – Have data owners approved the sources being used? Do the connectors, channels and autonomous actions match the risk level?

Publish – Who can use the agent and in what environment? Is the production version separated from development?

Monitor – Can we monitor usage, changes in permissions, unusual actions and the handling of sensitive data?

Review – Is the purpose still valid? Are the permissions still appropriate? Does the agent still have an active owner?

Retire – How do we remove the identity, connections, permissions and publication without leaving access open?

Such a process does not need to be bureaucratic.

A simple intake form, risk level, recorded owner, list of data and connectors and a short Go/No-Go decision are more useful than a complicated policy that nobody follows.

The purpose of governance is not to stop organisations from creating agents. It is to ensure that the speed of experimentation does not turn into uncontrolled production access.

8. Five Questions for the CISO

Before expanding the use of agents across the organisation, the security team should be able to answer five questions clearly:

1. Do we know how many agents we have and who owns each of them?
2. Do we know which enterprise data each agent can access and who approved that access?
3. Do we know which connectors, APIs and actions it can use?
4. Have we defined operations that the agent must never perform without approval?
5. Can we determine retrospectively what the agent did and shut it down immediately in the event of an incident?

If an organisation cannot answer these questions, the problem is not AI itself.

The problem is the absence of proper management of identity, permissions and accountability.

9. Agent Governance Is Not an Entirely New Discipline

The security discussion around AI has long focused on what a model knows and what information it can find.

With agents, the question shifts: it is no longer only about what AI knows, but above all about what we allow it to do.

The good news is that organisations are not starting from scratch.

Most of the relevant principles come from IAM, Zero Trust, data governance, DLP and application security. What is new is the need to bring them together into a single functioning system and apply them to a new class of digital identities.

An agent can be a highly useful virtual colleague. But first, it needs a clearly defined role, appropriate permissions, oversight and someone who is accountable for it.