The agents are here - They are just not evenly distributed [1].
Having been on the EIC 2026 [2] in Berlin last week, I had the pleasure to listen to Patrick Parkers convincing presentation of his Laws of AI identity [1]. For those who are not aware of the history of the movement, the naming was a homage to one of the giants of the scene, Kim Cameron [2], who some 26 years ago published his seven laws of identity. It should be shortly be mentioned here, that Kim stood out of his peers not just by his contributions but even more as a gentle and erudite person.
While listening to Patrick's excellently presented contemplation on what needs to change, once we will seriously begin to sufficiently govern AI agents, some ideas were spawned in my mind. As AI agents were vastly dominating the topics and contents of the key-note speeches and the break-out sessions, some of my thoughts were later confirmed, others rather opposed. And a good part of them enjoyed both treatments.
Analysts as well as Consultants, very much in line with their business model, were mostly spreading fuzzy fears, while vendors, in line with their business models as well, presented solution concepts and at least claimed to be working on their implementation, hereby trying to instil confidence or hope at least. This gave the impression that vendors were conceptually ahead of analysts.
So, when the fear mongers bemoaned the lack of ownership, warned that an agent once spawned, could perform any action, regardless if in line with our original intent or not, cannot be controlled, even do not leave sufficient traces (log-files, audit trails or receipts) for successful forensic investigations, I wondered if there weren't even time-tested classic methods to at least reduce the chaos.
Not all agents are created equal
First of all - not all agents are created equal. As a human you may interact with an agent by impersonation, delegation or consuming a service. Those are 3 different scenarios.
If you consume a service, which is delivered by an AI agent, that agent might act on behalf of a business unit – most probably for marketing, sale or service desk operations. So, this 3rd type of agent resembles classic non-human identities (NHI) – from the consumer's view.
And then there is talk of a 4th type, completely autonomous agents, which act on their own behalf. Honestly, I haven't yet seen such a creature and I even struggle imagining them. But nevertheless, I am working on a fictional “self-driving entrepreneur” (no worries – just a publication coming soon). A closer look to it often revealed that such an agent, very much like a regular employee, is not tasked on a case-by-case basis, but, very much like a regular employee, is “permanently” assigned a business function by the organisation.
Impersonation
Let's start with agent type 1: Impersonation - So, these creatures act as you. The definition says: “Impersonation means that one subject temporarily assumes the identity of another subject and acts as if it were that subject. To the target system, the impersonator appears indistinguishable from the impersonated identity.” This is certainly a dangerous variant – at least as of today. If the agent is you, it has access to all your credentials, so he can do the work that you were meant to do. Would you trust that agent to always come up with the results, you had in mind? Most experts on the scene would vehemently deny that – at least as for now. So, we will leave this hazardous game to the suicidal brave or to very limited contexts.
Delegation
2nd there is Delegation. For those who want to dig one level deeper I added a chapter on “impersonation vs. delegation” in the appendix. But please keep in mind, that's only one level deeper. Well, delegation means that one subject explicitly grants another subject limited authority to act on its behalf while preserving the distinction between the original identity and the acting identity. So, the delegate does not become the delegator. Instead, authority is transferred without transferring identity.
In this sense delegation is a time tested, well known and often practiced management discipline. However, from the implementations I have seen in the context of identity management, we are still not very good at it.
When it comes to AI agents, we however should be sufficiently good at it. The delegation itself should be limited in scope and time – very much like a PAM-Session [3]. The agent should never have higher privileges that the delegator. If idle, because no delegation is active, the agent will have no access at all – at least in a zero-trust environment – well, except it should perform some activities exactly then, like life-long-learning. In that case the agent will be assigned a few standing “birth rights” during onboarding.
That reminds us, that the agent should undergo a so-called “Joiner-process” like human beings. It appears to be anyway prudent to treat it very much as a being – not a human being, but well, an artificial being, however intelligent we might classify it. Those few mature organisations, which already have transformed their complacent HR departments into an agile Total Workforce Management (TWM), might even add those open-for-work agents to their workforce and administer them according to the corporations' needs.
Consuming a service
The 3rd scenario (consuming a service) is a bit different by nature. While in the 2 cases above, you as the one invoking the agents, were fully accountable, in this case the accountability is with the service provider. This doesn't mean that there are no obligations left for you. In case that service provider is a regular supplier in your supply chain, several standards and regulations require you to perform regular 3rd party audits to ensure a sufficiently high level of security and professionality. But that's all not new to us.
1.5 What is left?
So, it all looks fine and we only have to implement well known practices – well, not quite. While we may regard “traditional” AI-ChatBots merely as text-savvy, intelligent search engines, an AI agent performs real actions with impact on the world around you. And no one knows what ideas may cross its mind. Nevertheless, the actions, it could possibly invoke must be confined to those its delegator would be allowed to too. Technically this could mean that we need to implement a Policy Decision Point (PDP) on the MCP-Server in order to ensure that. There may be however other solutions as well.
There is yet another issue that may or may not case problems. Humans may evolve while the years pass. The will certainly age by time, they may acquire new skills, they may marry, join a political party, change religion, even sex. But this will happen gradually across their lifetime.
AI models however, which sit at the heart of each AI agent, evolve much faster, within weeks they may morph beyond recognition. So, the question arises, if the agent, you want to employ, is still the same agent you collaborated with before, or if it meanwhile has acquired some nasty habits. So, should agents regularly undergo a process that the NIST SP 800/63 Standard calls Identity Assurance [3]? Very much like the often-repeated request of having a “human in the loop”, that doesn't really look feasible, at least not if it couldn't be automated.
More takeaways from the conference
Several other “insights” during the conference were so true, that they lacked any value.
- It's all about the right balance of risk appetite. – Hmmm, wasn't it about that since the very beginning?
- Policy is everything! – So true, but what now?
- As we will make use of agents as a standard mode, the acting identity will more resemble a hybrid human / workload identity. - The interesting part will be that AI will make machines more human like and on the other hand humans will be supported and augmented by machines in a way, that we in the end we will have difficulties to tell them apart. Well, that is obvious, but is it helpful?
Another interesting observation was, that if you ask “Do you trust the agent?” all experts cry “No, never !!!!” – but nevertheless they make heavy use of them, just distrustfully.
Another big topic was quantum computing or better "security in a post-quantum world". Here Dr. Michael B. Jones, another pillar of the movement since decades, pointed out that for 2 reasons the “quantum apocalypse” may be here already – but just not evenly distributes (another reference to William Gibson).
- First there might be data, currently safely encrypted, be “harvested” by intruders to be decrypted once quantum decryption will be readily available. Well, we don't have any idea, if it will be of any compromising value for the attackers by then. Here we should keep in mind, that quantum computing during the last decades was always about 20 years away from now, a fate it shared with fusion energy.
- Second, and this is real right now, there are laws and regulations that oblige us to prepare for the post quantum security age. So, it seems to be a good idea to start activities for becoming quantum safe right now.
Much confusion existed on the term “intent”. “Purpose is not intent!”, was a much-heard battle cry. Nevertheless “intent” as well as “purpose” are terms on which we should soon de-confuse our minds by coming up with clear and commonly accepted definitions. I predict that either of these terms will become a new additional primitive for the identity world, very much like identity or authorisation.
Sovereignty, was a keyword of the conference as well. There were a few brave attempts to solve it on the technical and national base. But doubts remain if technical sovereignty will even be possible without political sovereignty. Perhaps we should build the foundation first, on which we confidently could erect technical and organisational service without fear of being gently forced by our big brother from across the big pond to do “the right thing”. As the EU, as we know it, will not save us, there are smaller movements like the “Europeans for the Planet”, which could eventually gain momentum in favour of a European multi-nation state.
A final word: When, after pausing for some years, I attended the EIC again 3 years ago, I was overwhelmed to meet so many old friends, colleagues and business partners. That was great. But the topics, problems, solutions, they were talking about, also were still the good old ones. So, did nothing change in-between? The brutally honest answer from several colleagues was bluntly “no”.
This time some things have changed considerably, I can confidently say. Let's make the best out of them.
2 Appendix
2.1 Impersonation vs. delegation
In Identity & Access Management, the distinction between impersonation and delegation is fundamental - both technically and from a governance/audit perspective.
A concise formulation would be:
- Impersonation = “I become you.”
- Delegation = “I act on our behalf.”
That sounds subtle, but the consequences are profound.
2.2 Impersonation
Definition
Impersonation means that one subject temporarily assumes the identity of another subject and acts as if it were that subject. To the target system, the impersonator appears indistinguishable from the impersonated identity.
Typical examples:
- administrator logs in “as” a customer
- support engineer reproduces a user problem
- backend service executes under the client's security token
- Windows “Run as user”
In classical technical terms:
The acting entity adopts the security context of another identity.
Microsoft defines impersonation as:
"the ability of a thread to execute in a security context different from that of the process owning the thread."
Key Characteristics of Impersonation
| Characteristic |
Impersonation |
|
Visible identity |
Appears as original user |
|
Audit trail |
Often obscured |
|
Scope |
Usually broad/full |
|
Principle |
Identity substitution |
|
Accountability |
Potentially ambiguous |
|
User control |
Often weak |
|
Risk |
High |
|
Typical use |
Admin support/troubleshooting |
Conceptual Model
Admin ──becomes──► Alice
│
▼
Application
The application may only see:
User = Alice
not:
Admin acting as Alice
unless explicit “actor claims” or audit extensions exist.
This is precisely why impersonation is controversial in modern Zero Trust systems.
2.3 Delegation
Definition
Delegation means that one subject explicitly grants another subject limited authority to act on its behalf while preserving the distinction between:
- the original identity
- the acting identity.
The delegate does not become the delegator.
Instead:
authority is transferred without transferring identity.
Key Characteristics of Delegation
|
Characteristic |
Delegation |
|
Visible identity |
Both identities visible |
|
Audit trail |
Preserved |
|
Scope |
Usually constrained |
|
Principle |
Authority transfer |
|
Accountability |
Explicit |
|
User control |
Stronger |
|
Risk |
Lower |
|
Typical use |
Workflow/business processes |
Conceptual Model
Alice ──delegates approval rights──► Bob
│
▼
Application
The application sees:
Actor = Bob
On behalf of = Alice
This distinction is crucial.
2.4 The Central Difference
The most important difference is:
|
Question |
Impersonation |
Delegation |
|
“Who am I?” |
“I am Alice.” |
“I am Bob acting for Alice.” |
That single distinction affects:
- auditability
- liability
- non-repudiation
- least privilege
- forensic analysis
- governance
- compliance
2.5 Governance Perspective
From a governance perspective:
Impersonation
creates:
- attribution ambiguity
- audit difficulties
- excessive privilege risks
- “hidden actor” problems
This is why modern IAM increasingly treats unrestricted impersonation as dangerous.
Delegation
supports:
- explicit accountability
- constrained authority
- time limits
- scope restrictions
- policy governance
- traceability
Hence modern architectures strongly prefer:
- delegated authorization
- scoped capabilities
- “on behalf of” semantics
over pure impersonation.
2.6 OAuth / Modern API Perspective
Modern OAuth/OIDC systems increasingly distinguish these explicitly.
Impersonation
Token effectively says:
{
"sub": "alice"
}
Receiver believes:
- requester is Alice.
Delegation
Token may say:
{
"sub": "bob",
"act": {
"sub": "alice"
}
}
Meaning:
- Bob acts for Alice.
The act claim (“actor claim”) is an important modern mechanism.
2.7 Zero Trust Interpretation
Zero Trust architectures generally prefer delegation because it better supports:
- least privilege
- continuous verification
- provenance
- explainability
- auditability
Impersonation is often tolerated only for:
- emergency support
- break-glass operations
- tightly controlled admin scenarios.
2.8 AI Agent Relevance
This distinction becomes extremely important for AI agents.
Dangerous Pattern
Agent impersonates user
Meaning:
- agent receives full user authority.
This creates:
- huge blast radius
- poor attribution
- audit confusion
- privilege escalation risk.
Preferred Pattern
User delegates limited capability to agent
Example:
“Agent may book flights under €500 for 24 hours.”
That is:
- scoped
- constrained
- revocable
- auditable.
Modern agent governance discussions increasingly revolve around exactly this distinction.
2.9 A Useful Heuristic
A very practical rule:
Impersonation
answers:
“Pretend to be me.”
Delegation
answers:
“Act for me within limits.”
2.10 In Our Governance Vocabulary
This maps extremely well to our governance vs operations distinction.
Impersonation
tends toward:
- operational convenience
- opaque execution
- weak oversight
Delegation
aligns better with:
- governance
- policy intent
- accountability
- constrained execution
- evidence generation
which is why delegation fits much more naturally into:
- PAP/PDP/PEP architectures
- PBAC/ABAC models
- Zero Trust systems
- AI agent governance frameworks.
2.11 Further readings
- Curity - Impersonation Approaches with OAuth and OpenID Connect,
Curity. (2022, March 9). Impersonation approaches with OAuth and OpenID Connect. Curity Identity Server Learning Center. https://curity.io/resources/learn/impersonation-flow-approaches/ - This technical article explains multiple approaches for implementing impersonation and delegation within OAuth 2.0 and OpenID Connect ecosystems. It distinguishes between impersonation (“acting as”) and delegation (“acting on behalf of”) and discusses implementation mechanisms such as token exchange, embedded actor claims (act), and delegated scopes. The paper is particularly valuable because it links theoretical identity concepts with practical OAuth implementation patterns and highlights auditability and traceability implications in distributed systems. It is highly relevant for Zero Trust architectures, API security, and AI-agent authorization models.
- Microsoft Learn - Client Impersonation and Delegation,
Microsoft. (n.d.). Client impersonation and delegation. Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/cossdk/client-impersonation-and-delegation - This Microsoft technical documentation explains impersonation and delegation within the Windows COM/DCOM security model. It defines impersonation as the temporary adoption of another user's security context and distinguishes it from delegation, where credentials may be forwarded across machine boundaries. The document is historically significant because it shaped many later enterprise security and IAM concepts related to privilege propagation, trusted intermediaries, and constrained delegation in distributed systems.
- Microsoft Learn - Impersonation Levels (COM),
Microsoft. (n.d.). Impersonation levels (COM). Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/com/impersonation-levels
- This reference describes the four COM impersonation levels - Anonymous, Identify, Impersonate, and Delegate - and their respective security implications. The document provides a foundational taxonomy for understanding how authority propagation may be restricted or extended across distributed systems. It remains relevant for contemporary IAM and Zero Trust discussions because it formalizes distinctions between local impersonation and cross-system delegation, concepts still visible in modern OAuth, Kerberos, and workload-identity architectures.
- This reference describes the four COM impersonation levels - Anonymous, Identify, Impersonate, and Delegate - and their respective security implications. The document provides a foundational taxonomy for understanding how authority propagation may be restricted or extended across distributed systems. It remains relevant for contemporary IAM and Zero Trust discussions because it formalizes distinctions between local impersonation and cross-system delegation, concepts still visible in modern OAuth, Kerberos, and workload-identity architectures.
- IAM World - From Impersonation And Delegation to Innovation,
IAM World. (2025, March 14). From impersonation and delegation to innovation: Embracing relationship-based access control in modern IAM. IAM World. https://iamworld.co.uk/from-impersonation-and-delegation-to-innovation-embracing-relationship-based-access-control-in-modern-iam/ - This article critiques traditional impersonation and delegation models in Identity and Access Management and argues for more advanced relationship-based access control (ReBAC) approaches. It highlights the governance and audit limitations of impersonation-centric architectures and proposes relationship-aware authorization as a more scalable and context-sensitive model for modern distributed environments. The paper is particularly relevant for AI-agent governance, collaborative systems, and policy-driven authorization architectures.
- Prefactor - Impersonation ≠ Delegation, Prefactor. (n.d.). Impersonation ≠ delegation: Don't let agents spoof your users. Prefactor. https://prefactor.tech/blog/impersonation-delegation-don-t-let-agents-spoof-your-users
- This article examines the distinction between impersonation and delegation in the context of AI agents and autonomous systems. It warns against architectures in which agents fully impersonate users and thereby inherit unrestricted authority. Instead, it advocates constrained delegation models that preserve provenance, accountability, and least-privilege principles. The text is especially important in emerging discussions about agentic AI governance, machine identities, and execution-time authorization controls.
- Learn IAM - Delegation, Impersonation, and “Acting As”,
Learn IAM. (n.d.). Delegation, impersonation, and “acting as”. Learn IAM. https://learniam.io/identity-fundamentals/delegation-impersonation-and-acting-as/ - This educational article introduces the conceptual and operational differences between delegation and impersonation in IAM systems. It explains how “acting as” semantics affect authorization decisions, auditability, and user accountability. The text provides accessible but technically accurate explanations suitable for IAM practitioners and governance-oriented audiences seeking to understand the implications of authority transfer in distributed systems.
- Microsoft Learn - When to Use Identity Delegation,
Microsoft. (n.d.). When to use identity delegation. Microsoft Learn. https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/external-authentication-services/when-to-use-identity-delegation - This Microsoft guidance discusses architectural scenarios where identity delegation is preferable to direct credential sharing or impersonation. The document explains delegation patterns in service-oriented architectures and APIs, particularly in the context of ASP.NET and OAuth-based systems. It is useful for understanding how delegated authorization supports layered service architectures while preserving security boundaries and accountability.
- arXiv - AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A,
Author(s). (Year). AIP: Agent identity protocol for verifiable delegation across MCP and A2A. arXiv. https://arxiv.org/xxxxx - This paper appears to address verifiable delegation and identity propagation between AI agents across Model Context Protocol (MCP) and Agent-to-Agent (A2A) communication frameworks. The topic is strategically important because it connects delegated authority, cryptographic provenance, and execution-time trust management for autonomous AI systems. Such work may become foundational for future agent governance and workload identity infrastructures.
[1] This an often-used reference to William Gibson's famous quote: “The future is already here - it's just not evenly distributed.”
[3] Privileged Access Management
[1] LinkedIn article by Patrick Parker, Parker, P. (n.d.). The laws of AIdentity. LinkedIn. https://www.linkedin.com/pulse/laws-aidentity-patrick-parker-zn9pe/
- In this article, Patrick Parker revisits Kim Cameron's influential “Laws of Identity” and reinterprets them for the emerging age of artificial intelligence, autonomous agents, and machine-driven interactions. The author argues that classical digital identity principles must evolve to address the growing presence of AI agents acting on behalf of humans and organizations. Themes include trust, delegation, provenance, accountability, and the governance implications of machine identities. The article is particularly relevant for discussions about AI-agent governance, verifiable delegation, Zero Trust architectures, and the extension of human-centric IAM principles into agentic and autonomous systems.
[2] Cameron, K. (2005, May). The laws of identity. Microsoft Corporation. [Kim Cameron's Identity Weblog](https://www.identityblog.com/)
- This foundational paper introduced the influential “Seven Laws of Identity,” a set of architectural and philosophical principles intended to guide the development of interoperable, privacy-preserving, and user-centric digital identity systems on the Internet. Cameron argues that the Internet lacked a native identity layer and proposes a universal “identity metasystem” capable of supporting multiple technologies and trust models. The seven laws - including user control and consent, minimal disclosure, justifiable parties, directed identity, pluralism of operators and technologies, human integration, and consistent experience across contexts - became highly influential in identity management, federated identity, privacy engineering, and later Zero Trust and self-sovereign identity discussions. The work is widely regarded as one of the seminal conceptual texts of modern digital identity architecture. ([identityblog.com][1])
[3] NIST SP 800-63A Digital Identity Guidelines: Enrollment and Identity Proofing Requirements, Grassi, P. A., Fenton, J. L., Lefkovitz, N. B., Danker, J. M., Choong, Y.-Y., Greene, K. K., & Theofanos, M. F. (2017). Digital identity guidelines: Enrollment and identity proofing requirements (NIST Special Publication 800-63A). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-63A
- This NIST Special Publication defines the technical and procedural requirements for digital identity proofing and enrollment in online systems. Central to the document is the concept of Identity Assurance Level (IAL), which measures the degree of confidence that an applicant's claimed identity truly belongs to the person presenting it. The publication defines three Identity Assurance Levels (IAL1–IAL3), ranging from little or no confidence in asserted identity to very high confidence achieved through rigorous identity proofing procedures. SP 800-63A forms part of the broader NIST SP 800-63 digital identity framework alongside Authentication Assurance Levels (AAL) and Federation Assurance Levels (FAL). The framework has become globally influential in digital identity governance, IAM architecture, Zero Trust security models, and regulatory compliance discussions.
