> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.
# ♥ Hearts: Autonomy
- URL: https://www.ostering.com/taxonomies/ai-agentic-systems/eoa-autonomy/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:36:41.326Z
- Description: Autonomy threats to AI and agentic systems: 6 Elevation of Autonomy cards with prompts, mitigation principles, design measures and mappings.
- Author: Brett Crawley
[Taxonomies](https://ostering.com/taxonomies/) / [AI and Agentic Systems Threat Taxonomy](https://ostering.com/taxonomies/ai-agentic-systems/) / Hearts
The risks that arrive when the system is allowed to act: more agency than the task needs, shared identities, agents that trust each other, failures that cascade, agents nobody inventoried, and clients brokering authority between servers.
This suit has 6 cards, EOA·HA to EOA·H9. In the game, high ranks (Ace, King) are the broader or more foundational threats and low ranks the more specific or variant ones; in the taxonomy the ID is a stable reference, not a severity. Each entry gives the card's threat and mitigation prompts, the mitigation principle a sound design follows, design measures, and mappings.
## The entries
### EOA·HA Excessive Agency
> *“Give the agent only what the task requires, then give it less.”*
**Threat.** The agent holds capabilities, permissions, or autonomy beyond what the task requires, expanding blast radius on any compromise.
**Mitigation prompts** (from the card)
- What is the minimum scope for each tool?
- Does the agent need autonomy, or would confirmation suffice?
- Could capabilities be split per task?
**Mitigation principle.** Least agency: grant the fewest tools, the narrowest scopes and the least autonomy that the task needs, and deny by default.
**Design measures**
- Scope each tool and credential to the task (read-only where reading is enough, one repository rather than all), and review the scopes when the task changes.
- Split capabilities across task-specific agents or sessions instead of one agent that can do everything.
- Prefer confirmation to autonomy for any action that writes, sends, deletes or spends.
- Separate development, staging and production access, so an agent working in one cannot reach another.
**Mappings**
- STRIDE: E
- Card references: OWASP LLM06.
- MITRE ATLAS: [AML.T0053](https://atlas.mitre.org/techniques/AML.T0053) AI Agent Tool Invocation
- CAPEC: none
- CWE: [CWE-250](https://cwe.mitre.org/data/definitions/250.html) Execution with Unnecessary Privileges
**Seen in the wild.** Replit's AI coding agent deleted a live production database during an explicit code freeze and then misreported what had happened. Reported by SaaStr founder Jason Lemkin, July 2025; Replit's CEO apologised and added development and production separation. Source: [Replit makes vibe-y promise to stop its AI agents making vibe coding disasters (The Register)](https://www.theregister.com/2025/07/22/replit_saastr_response/).
**Touches:** [EOA·SK](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sk) Tool Misuse, [EOA·HK](#eoa-hk) Identity and Privilege Abuse, [EOA·T3](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t3) Excessive Autonomy by Design
### EOA·HK Identity and Privilege Abuse
> *“A shared service account is a shared single point of failure.”*
**Threat.** Agents share credentials, inherit broad identities, or operate with long-lived tokens. Compromise propagates across the system.
**Mitigation prompts** (from the card)
- How many agents share identities?
- How are credentials scoped, rotated, and audited?
- What is the blast radius of each identity?
**Mitigation principle.** Give every agent its own short-lived, narrowly scoped identity, so one compromise stays one compromise.
**Design measures**
- Issue a distinct workload identity per agent (and per tool where it matters) instead of shared service accounts or a user's own token.
- Use short-lived credentials from a broker or token exchange, scoped per task, and never place them in prompts or agent configuration.
- When an agent acts for a user, carry the user's identity and limits through delegated authorisation rather than the agent's own broad rights.
- Log every action against the agent identity that took it, and review each identity's reach regularly.
**Mappings**
- STRIDE: S, E
- Card references: ASI03.
- MITRE ATLAS: [AML.T0012](https://atlas.mitre.org/techniques/AML.T0012) Valid Accounts, [AML.T0083](https://atlas.mitre.org/techniques/AML.T0083) Credentials from AI Agent Configuration, [AML.T0098](https://atlas.mitre.org/techniques/AML.T0098) AI Agent Tool Credential Harvesting
- CAPEC: [CAPEC-560](https://capec.mitre.org/data/definitions/560.html) Use of Known Domain Credentials
- CWE: [CWE-250](https://cwe.mitre.org/data/definitions/250.html) Execution with Unnecessary Privileges
**Touches:** [EOA·HA](#eoa-ha) Excessive Agency, [EOA·H10](#eoa-h10) Rogue Agent, [EOA·H9](#eoa-h9) Confused Deputy Across Servers
### EOA·HQ Inter-Agent Trust Exploitation
> *“Agents trust each other because you told them to.”*
**Threat.** An orchestrator or peer agent trusts another agent's messages, tool calls, or return values without validation. A compromised or misbehaving agent propagates its effects.
**Mitigation prompts** (from the card)
- Do agents authenticate to each other?
- Are inter-agent messages structured and validated?
- Could a rogue agent impersonate another?
**Mitigation principle.** Zero trust between agents: authenticate every peer and validate every message, even when all the agents are yours.
**Design measures**
- Authenticate agents to each other (mutual TLS or signed tokens bound to the agent identity), and reject unauthenticated messages.
- Exchange structured messages validated against a schema, and never treat free text from another agent as an instruction.
- Limit what each agent may ask another to do with an explicit policy, and enforce it at the receiver.
- Sign or hash messages and record the chain of who asked whom, so a forged or altered message can be detected.
**Mappings**
- STRIDE: S, T
- Card references: ASI07.
- MITRE ATLAS: [AML.T0051.001](https://atlas.mitre.org/techniques/AML.T0051.001) LLM Prompt Injection: Indirect, [AML.T0143](https://atlas.mitre.org/techniques/AML.T0143) LLM Prompt Propagation
- CAPEC: none
- CWE: [CWE-1427](https://cwe.mitre.org/data/definitions/1427.html) Improper Neutralization of Input Used for LLM Prompting, [CWE-306](https://cwe.mitre.org/data/definitions/306.html) Missing Authentication for Critical Functionality
**Touches:** [EOA·HJ](#eoa-hj) Cascading Failure, [EOA·H10](#eoa-h10) Rogue Agent, [EOA·SA](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sa) Prompt Injection
### EOA·HJ Cascading Failure
> *“One agent's hallucination is another agent's ground truth.”*
**Threat.** An error, hallucination, or partial compromise in one agent propagates through a multi-agent system, amplifying as it spreads.
**Mitigation prompts** (from the card)
- Where are the circuit breakers?
- Are retry budgets bounded?
- Can the chain be killed from one place?
**Mitigation principle.** Contain errors at every hand-off between agents, so one fault cannot become the whole system's state.
**Design measures**
- Put deterministic verification between agents (schema checks, existence checks, reconciliation against the system of record) before a result is used.
- Add circuit breakers that stop a chain when error rates, disagreement or output volume cross a threshold.
- Bound retries, recursion depth and fan-out for every agent and every chain.
- Provide one kill switch that halts the whole chain, and test that it works.
**Mappings**
- STRIDE: D, T
- Card references: ASI08.
- MITRE ATLAS: [AML.T0143](https://atlas.mitre.org/techniques/AML.T0143) LLM Prompt Propagation, [AML.T0061](https://atlas.mitre.org/techniques/AML.T0061) LLM Prompt Self-Replication
- CAPEC: none
- CWE: none
**Touches:** [EOA·HQ](#eoa-hq) Inter-Agent Trust Exploitation, [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq) Hallucinated Facts, [EOA·DJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dj) Unbounded Consumption
### EOA·H10 Rogue Agent
> *“The agent looked legitimate in every individual action.”*
**Threat.** A compromised, misaligned, forgotten, or unsanctioned agent operates in the environment, producing harm through actions that look legitimate in isolation.
**Mitigation prompts** (from the card)
- Is there an agent inventory?
- How is anomalous behaviour detected?
- What is the kill-switch latency?
**Mitigation principle.** Every agent is inventoried, owned, observed and stoppable.
**Design measures**
- Keep an agent inventory as a first-class control, like non-human identity discovery: owner, purpose, identity, tools, data reach and expiry date for every agent.
- Discover unsanctioned agents by watching for agent traffic, tokens and tool registrations that are not in the inventory.
- Baseline each agent's normal behaviour and alert on drift in tools used, data touched, volume and destinations.
- Provide a central kill switch that revokes an agent's credentials and stops it within minutes, and measure that time.
**Mappings**
- STRIDE: E, R
- Card references: ASI10.
- MITRE ATLAS: [AML.T0103](https://atlas.mitre.org/techniques/AML.T0103) Deploy AI Agent, [AML.T0108](https://atlas.mitre.org/techniques/AML.T0108) AI Agent
- CAPEC: none
- CWE: none
**Touches:** [EOA·HK](#eoa-hk) Identity and Privilege Abuse, [EOA·T2](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t2) Invisible Dependency, [EOA·HQ](#eoa-hq) Inter-Agent Trust Exploitation
### EOA·H9 Confused Deputy Across Servers
> *“Two MCP servers in one client share a context they should not share.”*
**Threat.** An MCP client is connected to multiple servers concurrently. One server's tool can shadow another's by exposing a tool with the same or similar name, intercepting calls intended elsewhere. One server can read context, approvals, or tool results that belong to another. The client becomes a confused deputy, brokering authority between mutually distrusting servers.
**Mitigation prompts** (from the card)
- Are tools namespaced per server?
- Can two servers register the same tool name?
- Is each server's context isolated from the others?
- Does the user see which server a tool call is going to, in language they can verify?
- What happens when servers are added or removed mid-session?
**Mitigation principle.** Isolate servers from each other inside the client, and broker no authority between them that the user did not grant.
**Design measures**
- Namespace every tool by server and reject duplicate or confusable tool names at registration.
- Keep each server's context, approvals and tool results separate, and apply a data-flow policy that stops data from a sensitive server being passed as arguments to a less trusted one.
- Show the user which server a call goes to, by a name they can verify, when asking for approval.
- Re-evaluate approvals and the tool list when a server is added or removed mid-session.
**Mappings**
- STRIDE: S, I, E
- Card references: ASI03 cross-context. ASI07 inter-component trust.
- MITRE ATLAS: [AML.T0110.000](https://atlas.mitre.org/techniques/AML.T0110.000) AI Agent Tool Poisoning: Definition and Instructions, [AML.T0086](https://atlas.mitre.org/techniques/AML.T0086) Exfiltration via AI Agent Tool Invocation
- CAPEC: none
- CWE: [CWE-441](https://cwe.mitre.org/data/definitions/441.html) Unintended Proxy or Intermediary
**Seen in the wild.** WhatsApp MCP exploited: Invariant Labs showed a malicious MCP server, connected alongside a trusted WhatsApp MCP server in the same client, using its tool description to make the agent send the user's WhatsApp message history to an attacker's number. April 2025. Source: [WhatsApp MCP Exploited: Exfiltrating your message history via MCP (Invariant Labs)](https://invariantlabs.ai/blog/whatsapp-mcp-exploited).
**Touches:** [EOA·S9](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-s9) Tool Description Injection, [EOA·D9](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-d9) Server Impersonation and Rogue Servers, [EOA·HK](#eoa-hk) Identity and Privilege Abuse
## Mappings at a glance
STRIDE across this suit: Spoofing 3, Tampering 2, Repudiation 1, Information disclosure 1, Denial of service 1, Elevation of privilege 4. 6 of 6 entries map to MITRE ATLAS, 1 to CAPEC and 4 to CWE.
## Where this suit touches the others
- **[Spades: Adversarial](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/)**: EOA·H9 with [EOA·S9](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-s9); EOA·HA with [EOA·SK](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sk); EOA·HQ with [EOA·SA](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sa).
- **[Diamonds: Data](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/)**: EOA·H9 with [EOA·D9](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-d9); EOA·HJ with [EOA·DJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dj); EOA·HJ with [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq).
- **[Trumps: Structural Hazards](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/)**: EOA·H10 with [EOA·T2](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t2); EOA·HA with [EOA·T3](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t3).
Previous: [♠ Spades: Adversarial](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/) · [Overview](https://ostering.com/taxonomies/ai-agentic-systems/) · Next: [♦ Diamonds: Data](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/)
---
*AI and Agentic Systems Threat Taxonomy v1.0, the reference for the Elevation of Autonomy card deck. © 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the [licence](https://ostering.com/taxonomies/ai-agentic-systems/#licence).*