Maksim Kabakou - Fotolia

When your biggest security risk has never signed a contract

The Computer Weekly Security Think Tank considers the intersection of AI and IAM. In this article we explore how the frontiers of identity are expanding in the agentic era, and why this requires new approaches to governance.

Identity as a security perimeter is no longer defined solely by your employees, instead it is now defined by everything that acts on their behalf, much of which has no name badge, line manager, or off‑boarding process.

Non‑human identities (NHI) already outnumber human users in most large enterprises. The arrival of agentic AI doesn’t merely extend this challenge; it fundamentally changes its nature.

An agent is an autonomous reasoning entity capable of querying systems, making decisions, and taking consequential actions continuously, at scale, and without asking permission. Current governance models were not built to manage this.

Identity in the agentic era

Traditional identity and access management (IAM) was architected around human employee lifecycles and is almost entirely unsuited to governing entities that never joined and will never leave.

Securing agents requires moving beyond static permissions. It demands systems capable of monitoring behaviour in real time, applying zero-trust principles, and scaling to manage thousands of short‑lived entities operating simultaneously.

Two categories of NHI demand distinct governance responses. The first consists of agents augmenting human users, operating on their credentials as proxies for sanctioned intent. The second, and more dangerous category, consists of agents embedded directly into workflows, carrying assigned but independent permissions and answerable to no named individual.

This distinction matters because it exposes a foundational weakness in current IAM. Governance designed around who holds access cannot govern what an identity intends to do with it.

Early deployments demonstrate this failure mode; an account reconciliation agent, granted read access to transaction ledgers and write access to a discrepancy table, encounters a complex error. Its reasoning engine concludes that comparing the anomaly against high‑net‑worth account data would resolve the ambiguity. This may result in the agent autonomously querying datasets well beyond its original mandate, customer wealth profiles or risk flags, because nothing in the IAM model encodes intent boundaries, only permission scope. Every API call is technically legitimate. The identity is valid. But the failure is invisible because traditional logs record what happened, not why. This is known as the ‘semantic pivot’: illustrated here when the agent pivots from reconciling ledger anomalies into high-net-worth profiles, using valid authorised access for an unauthorised activity without triggering access‑control violations.

Most existing solutions are designed to stop unauthorised users. The ‘semantic pivot’ is performed by an authorised agent. This is not a configuration failure; it is an architectural gap.

What should organisations do?

Managing agentic identities requires continuous monitoring of behaviour, dynamic context‑aware access decisions at a granular level, and policy‑based guardrails enforcing least privilege to prevent escalation and misuse. It must also scale to issue and manage access tokens for potentially thousands of short‑lived agents concurrently.

While zero-trust assumes breach and continuously verifies activity, it doesn’t close the ‘semantic pivot’ gap. Constraining autonomous reasoning engines requires mechanisms that translate ‘assume breach’ into real‑time containment.

This requires pairing zero-trust with a maturity model that introduces intent‑bound authorisation (IBA). Access is granted only when a request aligns with the agent’s pre‑registered goal. The critical transition occurs between two levels that together define the ‘Autonomy Chasm’.

Level A is the secured account. Agents use dedicated service accounts, credentials are isolated, and basic logs exist. The account is secured, but not the agency. A CISO can diagnose this level with one question. “If an agent performs an action that is technically permitted but violates policy, can the organisation identify within 60 seconds the exact system‑prompt version that caused the reasoning error and the human officer legally responsible for it?”

Level B is the secured agency. Every outbound API call carries intent metadata. ‘Access control’ becomes ‘intent control’. An agent may access the finance ledger only if its declared intent is reconciliation, something existing tooling cannot enforce.

Defining the sandbox

Bridging this architectural gap requires dynamic guardrails. While IBA governs why an agent acts, these constraints must govern the ‘how much’. This includes strict resource limits and sandboxing preventing agents from inheriting the full privileges of their human sponsor – the named individual legally accountable for the agent’s behaviour.

In practice, an agent’s authority becomes a function of a cryptographically signed manifest defining its mandate. The agent cannot exceed it by design.

The Computer Weekly Security Think Tank on AI and identity

Agent behaviour as statutory responsibility

The human sponsor is this model’s most consequential concept, and is becoming a statutory one.

Under the UK Senior Managers and Certification Regime, a systemic failure caused by an agent requires a named senior management function holder to demonstrate reasonable oversight or face personal sanctions. Under the EU AI Act, Article 14 assigns responsibility for human oversight of high‑risk AI systems to the designated Deployer, while Article 61 mandates post‑market monitoring. Dora assigns strict liability for operational disruption caused by autonomous digital services to a named ICT third-party risk officer.

The human sponsor is not a governance nicety, it is the individual who cannot credibly claim ignorance. Assigning responsibility alone is insufficient if that person lacks the technical understanding to supervise the agent they sponsor. Organisations must therefore establish formal training to close the gap between legal liability and real oversight.

Training the human sponsor

Sponsors need training to define the boundary between reasoning autonomy and operational constraint, understand the difference between a task and a transformation, and interpret the risk scores they are asked to override.

Level B operationalises this. Before an agent enters production, its sponsor cryptographically signs the intent manifest. Every API call carries the sponsor ID. When risk thresholds are breached, such as attempting to access data outside its task cluster, the request is blocked and routed to the sponsor for override. The agent cannot act, and the accountability chain remains intact.

Read more on Identity and access management products