When the IA stops responding and starts acting in the companies

We are witnessing a profound mutation in the way artificial intelligence is incorporated into the daily work of companies. In recent years, adoption has focused on conversational and copilotic assistants who answer questions, summary texts or facilitate searches. However, the current trend is that of IA agents capable not only of dialogue, but of planning, reasoning and implementing actions in business systems on behalf of users or organizations.

This leap - from "responding" to "acting" - completely changes the risk landscape. New actors do not just show information: they interact with applications, consult databases, launch workflows and, in some cases, modify resources. This capacity to intervene transforms the IA into an entity that requires controls other than those of a traditional bot.

Not all agents create the same danger. The level of risk depends primarily on two variables: what they can access and how much independence they have to act without human supervision. An assistant who only searches for local documentation poses a very different risk to an agent who can, for example, run cloud deployments or change critical settings.

In practice, at least three families of corporate agents should be distinguished. The first versions are the chatbots integrated into managed platforms: they appear in productivity tools, customer care systems or knowledge bases and are activated with human interaction to recover or condemn information. They are often of low autonomy, but are not without problems: if they use connectors with static credentials or too wide permits, they become privileged access doors to sensitive resources.

The second category, and probably the most problematic because of its rapid expansion, is the local agents that run in the endpoints of the employees. These assistants are integrated with code editors, terminals, analysis tools or automated scripts and inherit the credentials and permissions of the user who runs them. This property facilitates adoption because it eliminates centralized supply steps, but also generates a governance hole: each employee can, without being so aware, turn his working environment into an action vector with corporate permissions.

The third group is the production agents: continuous services that orchestrate complex tasks, respond to events and act without human intervention. They are used to automate incident response, DevOps pipelines or business processes and operate with dedicated machine identities and credentials. Here the risks are more evident because they combine high autonomy, access to critical infrastructure and, often, the processing of external inputs that may contain malicious instructions.

The driving thread between these scenarios is identity. Each agent is in fact a new kind of digital identity within the company: he asks for tokens, consumes APIs, writes in repositories and shoots jobs. If these identities are poorly managed - excessive permissions, uncontrolled life cycle, defective rotation - the agent becomes a window for attackers or a source of errors with operational and regulatory consequences.

In addition, the typical configuration of architectures with multiple agents can generate hidden chains of trust: one agent can invoke another and thus scale privileges or spread unintended actions. And you don't have to underestimate the exposure to instructions injections (prompt injection), a vector where external inputs manipulate the model's behavior to induce it to perform unwanted actions; on this subject it is necessary to review specialized resources such as the OWASP guide on prompt injection ( OWASP Prompt Injection).

For those who lead security (CISUS), the priority is no longer to discuss whether the IA will enter the organization and to identify where it is already and how it operates. It is necessary to know which agents exist, which identities they use, which systems they can access and whether these permits correspond to the stated purpose of each agent. This vision is the basis for deciding which order to address risks and which controls to apply.

Some references of good governance and risk management can help to structure that response. The NIST IA risk management framework provides principles and tools for assessing and mitigating specific risks of intelligent systems ( NIST TO RMF), while NIST's digital identity guides are useful to understand how the life cycle of human and machine identities should be managed ( NIST SP 800-63). At the end of the supply chain, the recommendations of the United Kingdom National Cybersecurity Centre on software supply chain security are valuable for mitigating risks associated with plugins and external units ( NCSC Software Supply Chain Security).

In practical terms, organizations should invest in detection and visibility: discovering deployed agents, inventing identities and recording their actions. From there, it is appropriate to apply the principle of less privilege and dynamic access mechanisms that limit what each identity can do and for how long. The automatic rotation of credentials, the use of federated identities and the control of the use of third-party plugins are measures that reduce the threat surface without stopping productivity.

No less important is to implement telemetry: traces, audit records and alerts that allow for the recognition of abnormal behaviour of an agent. Resilience tests against adverse instructions and safe validation of external inputs help to tackle vectors such as the injection of prompts. To design these tests it is appropriate to consult good practice of platforms offering models and APIs, which often include specific safety recommendations ( OpenAI Security Guidance) and documentation on responsible artificial intelligence by cloud suppliers ( Microsoft Responsible AI).

The paradox of the age of the agents is that the speed and autonomy that make them so useful are also those that require a rethinking of traditional controls. The identity and access tools designed for humans and for conventional services are not enough: solutions are needed to manage the identities of agents on a scale, with provision, temporary access rules, automatic rotation and audit capabilities specific to automated activities.

In the end, securing the IA is not to ban it, but to govern it. The organizations that move forward faster will be those that know how to map their agents, align permits with operational intentions and apply identity controls as a control plan. In this sense, identity is no longer a component of architecture: it becomes the central lever to allow the safe adoption of agents acting without frequent human supervision.

If your company is deploying or evaluating agents, it is appropriate to start with an inventory, define risk criteria based on access and autonomy, and prioritize controls on those agents with the greatest impact capacity. The literature and patterns of agencies such as NIST and the security teams of platform providers provide solid frameworks to structure this transition to an IA that provides value without compromising security.