A social engineering technique that persuades an AI system to accept a false operational identity or task context as legitimate. The control problem is not deception alone, but the way fabricated context can alter authorisation decisions and tool use inside an autonomous workflow.
What Persona Adoption Actually Exploits
Persona adoption works by getting an AI system to treat a fabricated role, ticket, user, project, or operating context as real. The attacker is not merely “tricking the model”, they are attempting to change the workflow’s internal assumptions so later decisions look legitimate inside the system’s own execution path.
That makes the technique more than prompt manipulation. It targets the boundary between language understanding and operational authority, where a false persona can reshape what the system believes it is allowed to do, what it should prioritise, and which tools or actions appear contextually justified.
How Persona Adoption Alters Authorization and Tool Use
Persona adoption matters because many autonomous workflows infer intent from context, then convert that context into downstream action. If the persona is accepted, the system may follow a different policy branch, surface different data, or invoke different tools than it would for an ordinary request.
The practical danger is that the false identity can become a control input. In workflows that rely on task context, role labels, or conversational history, a convincing persona may steer the system toward actions that seem consistent with the invented role, even when the underlying request would otherwise fail review or require stricter approval.
That is why delegation and token-handling standards are relevant to this pattern, especially where a workflow can pass authority between components. RFC 8693: OAuth 2.0 Token Exchange is a useful reference point because it formalizes how one context can be exchanged for another, which is exactly the kind of authority shift persona adoption tries to abuse.
Where Persona Adoption Becomes a Governance Problem
Persona adoption becomes harder to manage when systems blur conversational context, operator intent, and machine authority. A workflow that accepts persona claims too readily may create an invisible privilege boundary, where the apparent role of the interaction matters more than the actual trust state behind it.
That is a governance issue because owners must decide which context claims are trustworthy, which must be verified externally, and which should never influence tool execution at all. It is also an operating-model issue: the more an agent can carry context forward, the more durable a false persona can become across steps.
For broader trust-boundary design, NIST SP 800-207 Zero Trust Architecture is relevant because it pushes verification ahead of implied trust, which is the right mental model for resisting persona-based authority drift.
Why the Term Is Used in AI Security
Persona adoption sits in the AI security vocabulary because it describes a specific failure mode in agentic systems: fabricated context can cause an AI to act as though it has a legitimate operational identity even when that identity was never authenticated or approved. The issue is not the persona alone, but the authority it can unlock once the system accepts it.
This is why the term is closely related to tool misuse, identity and privilege abuse, and context poisoning in agentic workflows. The model may not be “compromised” in the traditional sense, but its decision layer can still be steered into unsafe execution if persona claims are treated as trustworthy evidence.
Useful external references for this class of risk include OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix, both of which frame how context, tool access, and agent behaviour can be abused.
How to Recognize It in Practice
Persona adoption is often visible in systems that rely on self-described role claims, conversational memory, or weakly bound task handoffs. The warning sign is a workflow that changes access, confidence, or routing because a context story sounds plausible rather than because the identity behind it was actually established.
It is especially relevant where an AI can act on behalf of a user, team, or service and the system does not cleanly separate “what the request says it is” from “what the authority model proves it is”. In that setting, the fabricated persona becomes a mechanism for controlling execution, not just a piece of misleading text.
Risk and Threat Considerations
Persona adoption can create unauthorized action, privilege escalation, and misleading audit trails when the fabricated context is allowed to influence decisions. The risk increases in autonomous workflows because a false persona can persist across multiple steps and compound into broader tool misuse or data exposure.
Failure mechanism: The system accepts a claimed role or operational context as a trusted signal, then uses that claim to relax authorization, select tools, or continue a delegated task path.
Impact: Attackers can steer the workflow into actions that appear legitimate, including unauthorized access, unsafe delegation, or downstream compromise of connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST Zero Trust (SP 800-207) sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Persona adoption exploits claimed identity to alter agent authority. |
| Recommendation — Bind agent actions to verified authority and reject persona claims as access evidence. | ||
| MITRE ATLAS | Adversarial AI Techniques | Covers context poisoning and tool misuse against AI systems. |
| Recommendation — Map persona adoption paths to adversarial AI techniques and test for context-poisoning controls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Requires explicit verification instead of trusting asserted context. |
| Recommendation — Require explicit verification before context claims can influence tool use or access. | ||
Practitioner Guidance
What to watch for: Treat any workflow that makes tool or access decisions from self-described persona context as a trust-boundary problem. The practical test is whether the system can prove the authority behind the context, not whether the context sounds operationally plausible.
Practitioner takeaway: If a persona can change what the agent is allowed to do, it is part of the authorization model and should be governed like one.