Identity with intent: the key to controlling the IA agents already operating in production

Just a couple of years ago, deploying artificial intelligence in the company used to mean assistants who wrote emails or summarized documents. Today, these same systems have ceased to be mere copilots: they provide infrastructure, resolve support tickets, prioritize alerts, approve transactions and even write code that comes to production. In short, IA agents are no longer passive assistants: they act as operators within the organisation.

This forces those responsible for security - the CISUS - to refocus a known but now much more complex problem: access control. Each agent is authenticated against APIs, cloud services and third party tools using keys, tokens OAuth, cloud roles or service accounts. Read data, write settings and chain calls to other systems. In the technical world, an IA agent behaves exactly as an identity, and yet in many environments he is not governed as such.

The operational reality is simple and dangerous: many agents inherit privileges from their creator, run with accounts too wide to "make everything work" and evolve faster than the controls around them. This combination produces what can already be considered a blind area emerging in the security of IA. The first obvious answer is to apply an identity approach to the agents: treat each agent as a first-class identity with life cycle, property, roles and traceability. However, there is a second truth that complicates the picture: identity alone is no longer enough.

The traditional identity and access management (IAM) models answer a specific question: who requests access? In environments focused on static people or services that could be enough because the roles and functions were predictable. But IA agents are dynamic by design: they interpret objectives, plan steps and chain tools according to context. An agent who starts with the mission of generating a quarterly report could, if directed or manipulated, try to access systems outside the report. A remediation agent can deviate and modify configurations that exceed its original purpose.

This behavior breaks the assumption of determinism on which static access is based: if the role allows, the action is executed even if it no longer coincides with the original reason of the agent's existence. Here comes the need for a step beyond the classic IAM: intended-based permits If identity responds to "who," intention responds to "why."

Allow an agent to activate privileges only when its declared mission and implementation context justify such activation transforms access control. Instead of a static map between identity and permissions, the system assesses whether the purpose and conditions in time of implementation would allow such access. For example, a deployment agent could have the capacity to modify infrastructure, but these privileges are activated only if the action is carried out from an approved channelling and in response to an authorized change. If the same agent tries to touch production outside that flow, the credentials do not allow the operation.

This composite approach reduces two recurring failures. On the one hand, the inheritance of privileges: it is common for developers to test agents with high own credentials and those credentials remain in production. If each agent has his own and managed identity, that "bleeding" disappears. On the other hand, the drift of mission: the agents can pivote for prompts, integrations or attacks; the policies based on intention prevent this pivot from becoming unauthorized access.

But beyond the closure of specific risks, there is a powerful organizational argument: governance that scale. In ecosystems where an agent can invoke thousands of APIs and resources in multiple clouds and SaaS, managing each permit as a separate rule quickly leads to a difficult policy explosion. A model of intention simplifies monitoring: instead of reviewing every possible call, those responsible audit approved identity profiles and intent limits. Policy reviews focus on whether the authorized mission makes sense, not on inventing every endpoint an agent could play.

Tracability also improves. In one incident, not only does it matter to know which identity carried out an action, but what intention profile was active and whether the operation was aligned with the authorized mission. This context granularity is increasingly relevant for accountability to executive regulators and directories. For technical equipment, it also facilitates research and rapid response.

These ideas are not just theory: they link with frameworks and practices that have been consolidating in security for years, such as Zero Trust principles or attribute-based models. Resources such as the NIST IA risk management framework (RMF NIST), access control recommendations based on attributes (NIST SP 800-162) and the Zero Trust strategy (NIST SP 800-207) offer principles that fit this identity + intention approach. In addition, organizations such as the Cloud Security Alliance Community projects such as OWASP are beginning to document risks and specific controls for IA systems.

And what practical measures can the security teams begin to implement today? The road starts with a clear inventory of agents and their capabilities, assigning them unique identities with life cycle management and responsible owners. It is therefore appropriate to define, in writing, the approved mission of each agent and the operational limits on which it can act. Such documentation should be integrated with technical mechanisms that condition the activation of privileges to the match between identity, declared intention and context in time of execution.

In parallel, monitoring must be implemented: enriched records showing not only what was done and by whom, but what was the associated intention and what context signs (pipeline, origin of the request, multifactor authentication, etc.) allowed the action. Finally, automating the rotation of credentials, the end-of-life revocation and regular mission diversion checks reduces exposure and clarifies governance.

The alternative is dangerous: allowing autonomy without governance multiplies the risk; having an unintended identity leaves gaps. In the agentic age, understanding who acts is necessary, but making sure that it acts for the right reason is what makes IA safe. For CISUS, adapting processes, tools and policy review to this reality is not an option, it is an obligation to maintain control, compliance and resilience.

If you want to go into practical frameworks and recommendations, start with the NIST resources on IA and access control I mentioned, and with the documentation and good practices published by initiatives such as the Cloud Security Alliance. The conversation about how to put in place identity controls and permission by intention is just beginning, and it is essential that it be faced by security, engineering and compliance teams in a coordinated manner.