[Theme] Access Control and Security Policy Enforcement with Metamorphing AI Agents

Theme Name

Access Control and Security Policy Enforcement with Metamorophing AI Agents

Proposer(s)

Artur Hecker, <artur.hecker@huawei.com>, Huawei Technologies Duesseldorf GmbH, Munich, Germany
Evangelos Haleplidis, <haleplidis@isi.gr>, Industrial Systems Institute, Patras, Greece

Summary

We observe a direct contradiction between the stable, verifiable identity on the one hand and an intrinsically probabilistic and radically changing behavior of an AI agent on the other hand. Therefore, differently from classical software, we need to accept that a typical, flat identity (e.g., derived from a public key) of an AI agent can say nothing about how the Agent will behave for a given request/task; similarly, the fact that an Agent misbehaved might not be a sufficient reason for action. Overall, it emerges that using a stable identity as a basis for AI Agent authorizations or revocations is not really sound.

In this theme, differently from the state of the art, we suggest studying new ways how a metamorphing entity such as an AI Agent can be represented and handled in the scope of (classical) security policies and security policy enforcement.

Scope / Open Questions

1. With classical security policies revolving around the access control matrix and its transformations, how could an alternative identification scheme for AI Agents look like?

Potential deliverables:
- A study on AI Agent internal design and its internal dependencies, formalization of relationships typically encountered in the popular agents, assurances that can be produced in this regard, and the corresponding trust models.
- Requirements for a naming scheme for AI Agent along with details of corresponding mechanisms capable of formally and deterministically packaging these assurances into an identity string to be used for granting and revoking access rights.

2. How could we express security policies differently, notably to avoid the problem with the identity-behaviour mismatch? Could a security policy be written as a higher level intent? Should the security enforcement be left over to AI Agents as well?

Potential deliverables:
- Study of possibilities how a security policy could be expressed as "an intent" regardless of the involved actors and agents. Understanding of features and limits of such policies.
- Study of coexistence of classical security policies with intent-based security policies.

Related Work

1. Perrier E, Bennett MT. Agent Identity Evals: Measuring Agentic Identity. arXiv preprint arXiv:2507.17257. 2025 Jul 23.
   This paper argues that agents' identity erodes over time and proposes metrics to measure it.

   This one supports the metamorphing claim.

2. Zhang Y, Zhang ZH, Qin H. Which Model Is Actually Serving You? IRIS: Budgeted Black-Box Auditing of Model Substitution and Routing Dilution in LLM Gateways. arXiv preprint arXiv:2607.20860. 2026 Jul 23.

   This paper finds whether an LLM API is actually serving you what you pay, meaning you may say I’m using blah LLM, but instead you’re been served a weaker model. Which makes it even worse when you’re trying to verify the reasoning/trust of an agent.

3. Kasselman P, Lombardo J, Rosomakho Y., Campbell B., Steele N., Parecki A. AI Identity Management System. IETF draft draft-ietf-wimse-aims-00, 2026, Sep 15.

   an IETF draft that views agents as workloads and gives agents a stable WIMSE/SPIFFE identifier with short-lived credentials, and it attenuates or revokes access when security signals arrive.

4. Raskar R, Chari P, Zinky J, Lambe M, Grogan JJ, Wang S, Ranjan R, Singhal R, Gupta S, Lincourt R, Bala R. Beyond dns: Unlocking the internet of ai agents via the nanda index and verified agentfacts. arXiv preprint arXiv:2507.14263. 2025 Jul 18.

   This is about the MIT NANDA project and AgentFacts. They have a lean, stable index that maps each agent identifier to pointers to AgentFacts, i.e., dynamic documents signed as W3C Verifiable Credentials that describe the agent's endpoints, capabilities, versioned metadata, evaluations and certifications. AgentFacts can be updated frequently without touching the index. So something like an invariant/variant point of view.

5. A2A Protocol, Linux Foundation

   Linux Foundation project that contains an Agent Card which is a self-describing manifest for an agent. It provides essential metadata including the agent's identity, capabilities, skills, supported communication methods, and security requirements. However the spec from a brief view, does not identify how changes in an agent reflects the current state of the Agent Card.

6. Huang K, Narajala VS, Habler I, Sheriff A. Agent name service (ans): A universal directory for secure ai agent discovery and interoperability. In2026 IEEE 5th International Conference on AI in Cybersecurity (ICAIC) 2026 Feb 18 (pp. 1-9). IEEE.

7. Scott Courtney, Vineeth Sai Narajala, Ken Huang, Idan Habler, and Akram Sheriff. Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity. Internet-Draft draft-narajala-courtney-ansv2-01, Internet Engineering Task Force, April 2026. https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/01/ : Accessed: September 2026.

Initially the paper 6. and then the second version 7. as an independent IETF draft to anchor an agent's identity to a domain name whose ownership a Registration Authority (RA) has verified. Second, every change to the agent's software produces a new version number and a new Identity Certificate, recording which version is registered. Third, every lifecycle event is sealed into a Transparency Log, an append-only ledger where entries cannot be altered or removed after the fact.

8. Model Context Protocol Specification, version 2026-07-28. Agentic AI Foundation, Linux Foundation. https://modelcontextprotocol.io/specification/2026-07-28, accessed September 2026.

The standard protocol for connecting agents to tools and data. An agent's set of tools can change during operation, and tool definitions are declared by the server itself. The agent's effective capabilities can therefore change without any change to its identity, making tools a variant property of the agent by design.

9. OWASP Gen AI Security Project, Agentic Security Initiative. OWASP Top 10 for Agentic Applications 2026. December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

Identifies the mismatch between user-centric identity systems and agents (ASI03), behavioural drift from an agent's authorized scope (ASI10), and poisoning of tools, prompts and supply chain (ASI02, ASI04), including incidents involving MCP servers.

Related Themes

Mainly Theme #6, @cgorlla is relevant to #4.2 above.

More generally:
* Theme #6 — Intent-based Security Policies: Expression, Coexistence, and Runtime Verification: addresses expressing security policy as intent and verifying conformance at the moment of action. This theme would contribute the identity side of coexistence: how a design-trait identity is used by, and composes with, intent-based policies.
* Theme #22 — Remote Attestation for Agentic AI (RA-AAI): addresses what to attest for an agent and how, beyond the hardware. This theme would define the design invariants (stakeholders, software components, models, tools and their relationships) that such attestation needs to support.
* Theme #11 — Model-level Trust Foundations: addresses model provenance and baseline model behaviour. This theme would use model provenance as an input to the design-trait identity and examine which model traits can be treated as immutable.
* Theme #12 — Agent Trust Mechanics: addresses credentials, memory and context assurance, and confidential computing within an agent. This theme would separate an agent's immutable design traits from the mutable state that #12 protects.

Discussion

AI Agents are software workloads that can be characterized not only by constant evolution but by their unique capability to reason and to (often) achieve a satisfactory outcome in unforeseen situations. These agents are therefore meta-morphing, as they are not merely adjusting to the previous situations, maximize the objective function, etc., but rather they can change their entire behaviour, their approach, their solution methodology to something entirely different. Note that this is not only the defining trait of an AI Agent but also often the very reason why one would integrate an AI agent into an ICT system in the first place. Because of this unique property, there is an intrinsic contradiction between such a metamorphing software entity and the idea to bind it to a fixed, verifiable identity. Rather, we need to accept that an identity of an AI agent says almost nothing about how it will behave for a given request/task. Hence, using this identity for security policy enforcement is, in principle, a daunting exercise.

• With classical, identity-centric security policies (access control matrix), this might require a novel, AI-agent specific identity management system, capable of finding immutable design properties/traits of a given AI Agent and reflecting and using the latter in its naming mechanism. Here, the identity would not be a flat string, but rather an encoded expression of invariants, e.g., of the involved stakeholders, used software blocks, employed models and tools, incl. the relationships between the latter, in a try to match in the naming of an Agent the machinery inseparably involved in any of its inner workings. This view tries to pinpoint an identity not on the software entity per se, but on its immutable design traits, regardless of its operational behavior. Note that such naming scheme alone does not fully resolve the contradictions above, but it could be used to mitigate the effects from the operational experience: we might know that this and that model, from this and that integrator generally yield better results for a particular task class than this and that model from that other integrator. The proposed naming scheme, if tractable and feasible, can be used to formally express such experience in policies.

• Alternatively and in parallel, we need to rethink how we express security policies; for example, instead of the access control matrix mentioned above, we could try to use intents formulating properties to be preserved at all times regardless of the entities, actors and their respective identities. The idea here is to embrace the very technology we are trying to tame for the expression and consequent enforcement of the security policy; such security policies therefore might have an intrinsic fuzziness. It would be in scope of that stream of work to study co-existence of such novel access control models with the existing, strict ones.