For decades, enterprise cybersecurity was built around a relatively simple idea: protecting people and controlling their access to systems. Each employee received a username, password, and a set of permissions determined by their role. The finance team could access accounting information, the sales department worked within the CRM, and IT administrators managed critical infrastructure. If an individual left the organization, their credentials could be deactivated, and access would be restricted.
The arrival of AI agents is beginning to disrupt that model. A company can now have autonomous systems capable of querying databases, sending emails, updating sales opportunities, generating documents, making API calls, and coordinating entire processes across different platforms. These agents are not employees, but they operate within the company's infrastructure. They don't have a human identity, but they require credentials. They don't hold a traditional job title, but they can be granted exceptionally broad permissions.
This is where one of the new challenges of corporate cybersecurity arises: Non-human identities, known as NHI.
A non-human identity is a digital identity associated with a machine, application, service, automation, or AI agent that needs to interact with technological systems. Service accounts and API keys have existed for years, but agentic AI introduces a fundamental difference: now these identities can be associated with systems that interpret goals, plan actions, and make intermediate decisions.
Let's consider a sales agent connected to a CRM. To fulfill their role, they may need to consult with clients, review conversations, analyze opportunities, create tasks, and send information to other systems. Technically, the agent requires an identity and permissions that allow them to perform each of these actions. The problem arises when companies apply the same access models designed for human users or relatively static machine identities to these systems.
The Cloud Security Alliance It has highlighted the challenge of authenticating and authorizing agents that perform database queries, API calls, and other interactions with systems, while maintaining accountability and security policies. Identity is no longer a technical detail: it is becoming a central component of enterprise AI architecture.
The risk becomes easier to understand when we stop thinking of AI agents as chatbots. A traditional chatbot receives a question and generates an answer. Its capacity for action is usually limited. An intelligent agent can receive a goal, analyze information, and execute a sequence of tasks using different tools.
For example, a company might ask an agent to manage unfollowed leads. The system consults the CRM, identifies dormant opportunities, reviews past conversations, categorizes contacts, drafts personalized messages, and schedules new sales tasks. With the necessary integrations, it can even send communications or update statuses within the company's systems.
This capability represents a huge opportunity for automation, but it also expands the risk surface. The agent needs access to information and to execute actions. Each additional permission increases its operational capacity and, at the same time, the potential consequences of misconfiguration, a manipulated instruction, or unexpected behavior. Security shifts its focus from solely protecting the model to questioning... what can the identity representing the agent actually do?.
In many organizations, a common but dangerous technology practice exists: granting more permissions than necessary to expedite integration. A developer needs to connect a system and, instead of designing a specific access policy, uses credentials with broad privileges. The project moves quickly, and the permission restrictions are postponed for a future review that often never happens.
With AI agents, this practice can have far greater consequences. An agent initially designed to query information could end up using credentials that also allow it to modify that information. Another agent tasked with generating reports could have access to sensitive information that it doesn't actually need to complete its objective.
The difference is that an agent doesn't always execute a completely deterministic sequence. It can analyze context and select tools within the limits of its design. For this reason, the principle of minimal privilege This becomes even more important: each agent should only have access to the data and actions strictly necessary to fulfill their role. Unbounded autonomy is not business intelligence. It's an operational exposure that's difficult to control.
The next stage of enterprise AI will not consist solely of individual agents. Organizations are beginning to experiment with multi-agent systems where different artificial intelligences collaborate to complete complex processes. A sales agent might request information from a financial agent. This agent might consult another specialized system and return an analysis that is ultimately used to make a decision.
In that scenario, a difficult question arises: Who actually authorized the final action? The person who initiated the process, the first agent, the second agent, or the system that executed the modification.
Recent research on AI identity specifically highlights the challenges of recursive delegation and accountability when agents and sub-agents execute flows across organizational boundaries. This isn't a theoretical issue: as businesses connect agents to real-world processes, they will need to rebuild the entire authorization chain.
Traditional traceability was designed for relatively predictable users and services. Agentic ecosystems require knowing which agent initiated a task, what permissions it used, what tools it consulted, and what other agents participated before the final result.
Imagine five agents using the same API key to connect to an organization's CRM. From the system's perspective, all actions may appear to have been performed by the same technical entity. If an incorrect modification occurs, reconstructing exactly which agent made the decision can become a complex process.
This problem already existed with shared service accounts, but AI significantly increases its importance. As agents begin to operate more autonomously, the company needs to accurately identify who did what. A generic credential used by multiple automations eliminates some of that visibility.
That's why the individual identity of agents is becoming a new layer of technology governance. Each relevant agent should have a distinct identity, defined permissions, and auditing mechanisms capable of recording its activity. It's not enough to know that an API made a call. The organization needs to understand which agent requested it, for what purpose, and within what business process. Without that information, autonomy can quickly turn into opacity.
The Zero Trust model is built around a simple idea: do not automatically trust an identity simply because it is within the corporate infrastructure. Each request must be evaluated based on context, permissions, and established policies.
This principle is especially relevant for AI agents. An organization should not assume that an agent is trustworthy simply because it was developed internally or because it uses a recognized model. Its access needs to be restricted and monitored according to the task it is performing.
A sales agent who typically reviews opportunities shouldn't have automatic access to salary information. A finance officer doesn't need administrative privileges on the CRM. An internal assistant shouldn't be able to download the entire company document database simply because they have access to a search tool.
Academic research is already exploring Zero Trust frameworks specifically for multi-agent systems due to the limitations of traditional identity and access mechanisms versus dynamic agents and delegation between systems.
Traditional business systems typically operate using relatively predictable rules. An application executes pre-programmed functions, and security policies control which operations it can perform. Intelligent agents introduce different behavior because they use models capable of interpreting instructions, analyzing context, and selecting actions.
This creates new risk vectors. A malicious instruction might attempt to manipulate the agent's objective. External information could influence its behavior. A compromised agent could use legitimate permissions to execute actions that are technically authorized but do not correspond to the process's original intent.
OWASP GenAI Security Project It published its Top 10 list for agentic applications, developed in collaboration with over one hundred experts, researchers, and practitioners. The framework identifies specific risks of autonomous systems that plan, act, and make decisions in complex workflows. Among the problems highlighted by the project are goal hijacking, identity abuse, and runaway autonomous behavior.
AI security can no longer be limited to reviewing prompts. It needs to observe actions.
The speed of adoption explains why this issue is becoming a priority. Gartner It projected that 401% of enterprise applications will incorporate task-specific AI agents by the end of 2026, up from less than 51% in 2025. At the same time, the firm also anticipates that more than 40% of agentic AI projects will be canceled before the end of 2027 due to rising costs, unclear business value, or inadequate risk controls.
The data reveals a significant contradiction. Organizations want agents and are experimenting with them at a rapid pace, but they are still building the capabilities needed to operate them effectively.
McKinsey reported in its 2025 global AI survey that 23.1% of participants were already scaling some type of agentic AI system within their organization. More recently, its analysis of trust in AI found that security and risk are the primary barriers to scaling these systems.
Technology is advancing. The question is whether corporate control is advancing at the same pace.
Mature companies know how many people work within the organization, what roles they perform, and what systems they have access to. Identity and access departments can create, modify, and delete permissions based on each employee's work cycle.
With AI agents, a similar discipline will likely need to be developed. A company will need to know how many agents exist, who is responsible for each one, what business objective they serve, what data they query, what tools they use, and what permissions they have.
You should also understand its lifecycle. Who created the agent? When was it last updated? What version of the model does it use? What happens when the process it automates ceases to exist? Have its credentials been revoked?
This inventory will be especially important in the face of the growth of Shadow AI. If different departments begin creating agents without technological coordination, the organization can accumulate non-human identities that continue to have access to systems even after no one remembers why they were created. Governance begins with knowing what exists.
One of the mistakes we're likely to see in the coming years is designing overly general agents with excessively broad permissions. The idea of building a single "enterprise super-agent" capable of accessing the entire organization seems appealing from a user experience perspective, but it raises enormous security and governance challenges.
A more mature architecture links the agent's identity to their role. A collections agent needs a specific context and permissions. A support agent requires access to different information. A purchasing agent works with different systems and rules.
This helps limit the potential impact of an error and facilitates auditing. If a sales agent attempts to access a restricted financial source, the architecture can block the action because it doesn't correspond to their identity or purpose.
Identity then ceases to be merely that of a technical user. It becomes a representation of the agent's function, capabilities, and limitations within the organization. This shift will be fundamental for scaling autonomous AI securely.
Identifying an agent is only the first step. Companies also need to observe how it behaves over time. A system may start out functioning correctly and later change its behavior due to modifications in prompts, models, tools, data sources, or integrations.
Observability allows you to analyze what decisions the agent makes, what tools it uses, how much each execution costs, and where errors or deviations occur. When this information is linked to the agent's identity, the company can build a much more complete behavioral history.
This will be especially important in critical processes. It is not enough to initially authorize an agent and assume that it will continue to function in the same way indefinitely. Intelligent systems require continuous evaluation.
Trust in AI should not be permanent or automatic. It should be built on observable evidence. If an agent begins to exhibit anomalous behavior, the organization needs to detect it, reduce its permissions, or stop its operation before the problem spreads to other systems.
There is one simple question that every company should ask itself before connecting an AI agent to a critical process: If something goes wrong, can we stop it immediately?
The answer isn't always obvious. An agent can execute actions through different APIs, start threads, or coordinate with other systems. If the architecture wasn't designed with interruption and recovery in mind, stopping a chain of actions can be more complex than expected.
This concern is already reaching the regulatory debate. In June 2026, the Deputy Governor of the Bank of England, Sarah Breeden, indicated that agentic systems could require new forms of supervision in finance and mentioned mechanisms such as circuit breakers or kill switches to address potential disruptions caused by autonomous AI.
The ability to stop an agent does not represent a technological failure. It is a measure of resilience. Critical business systems have always needed contingency mechanisms. Autonomous AI should be no exception.
Preparation begins by accepting that agents cannot be treated simply as another application. They are components capable of acting within the organization and, therefore, require controls related to identity, authorization, traceability, and lifecycle management.
The first step is to identify all existing intelligent agents and automations. Next, it's necessary to define responsibilities, business objectives, and the systems each agent can access. Permissions should be designed using the principle of least privilege and reviewed regularly.
The organization also needs to separate identities, avoid shared credentials, record delegations between agents, and build observability over critical actions. Finally, there must be revocation mechanisms capable of withdrawing permissions or stopping agents when unexpected behavior occurs.
It's not about building bureaucracy around Artificial Intelligence. It's about creating an architecture that allows it to scale. Companies that try to manage one hundred agents with the same controls used for five automations will likely quickly discover the limitations of their technological model.
In The Cloud Group We help organizations design technology ecosystems ready to integrate Artificial Intelligence, autonomous agents, and intelligent automation into real business processes. Our approach starts with architecture, data, and integration because an agent can only be as reliable as the system it operates on.
We analyze how CRM, ERP, APIs, internal platforms, and data sources connect to design workflows where AI can operate within clearly defined boundaries. Governance, observability, and security are not added after the agent is developed; they must be part of its design from the outset.
The next generation of businesses will have more digital identities operating within their systems. Some will belong to people, and others to intelligent agents. Preparing for this reality requires rethinking permissions, traceability, and control.
Because implementing agents is relatively easy. Building a company capable of managing them when they start to multiply is the real challenge.
A non-human identity is a digital identity used by a machine, application, automation, or AI agent to interact with technological systems. In agent environments, these identities allow users to query databases, utilize APIs, and execute actions. Managing these identities is important because agents can operate with varying degrees of autonomy and require clearly defined permissions.
Because a company needs to identify which system executed each action. If multiple agents share the same credentials, traceability is reduced, and it becomes more difficult to determine who modified information or initiated a process. A distinct identity facilitates auditing, permissions management, and access revocation.
A traditional service account typically executes pre-programmed tasks. An AI agent can interpret context, select tools, and coordinate different actions. This greater autonomy introduces additional needs for control, observability, and contextual authorization.
This means granting each agent only the permissions necessary to perform their role. A sales agent shouldn't automatically have access to all financial information, and a support agent doesn't need administrative privileges over all systems. Limiting access reduces the potential impact of errors or unexpected behavior.
The company may lose visibility into which agent performed a specific action. It also increases the difficulty of revoking permissions individually and analyzing incidents. Separating identities allows for more accurate activity logs and improved governance.
This is the application of the principle of not automatically trusting an agent simply because it is part of the enterprise infrastructure. Each request must be evaluated based on identity, permissions, context, and policies. The goal is to control what the agent can do in each situation.
You need to build a centralized inventory of agents, intelligent automations, and non-human identities. The registry should include the responsible party, purpose, connected systems, permissions, credentials, and operational status. This practice will become increasingly important as AI adoption grows.
For decades, enterprise identity management was designed around employees, vendors, and administrators. Organizations learned to create users, assign permissions, and revoke access when someone left the company.
Artificial intelligence agents are introducing a completely new category of digital actors. They can query information, use tools, coordinate processes, and execute actions within the same systems where people work. The difference is that they can operate continuously and at a speed impossible for a human team.
The potential is extraordinary, but autonomy needs limits. As companies incorporate dozens or hundreds of agents, identity, permissions, and traceability will cease to be technical details. They will become core components of AI governance.
Organizations that begin building these capabilities now will be better prepared to scale intelligent automation. Those that simply connect agents to systems using broad credentials may discover too late that they have a new digital workforce operating within their infrastructure without a clear control model.
The question will no longer be solely What can your AI agent do?.
The question that will define the company's security will be much more important:
Who is that agent, what does he have access to, and can you arrest him when necessary?
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
