Failure pathways
Exploit paths, root causes, and blast-radius analysis across agent runtimes.
Published openly by BlockSiFr · Identity and Execution Governance
THE IEG FIELD MANUAL
Identity and Execution Governance
for Autonomous Systems
AI systems do not fail loudly. They fail quietly, and still act.
The public practitioner field manual for identifying, containing, governing, remediating, reversing, and proving failures across the AI execution stack.
Govern what systems may cause.
01 · Thesis
The assistant did not merely make a mistake. The assistant executed.
Classical software security assumes deterministic behavior: bounded inputs, explicit logic, and predictable execution paths. Those assumptions break when probabilistic inference systems can call tools, use identities, modify systems, move data, initiate transactions, and alter infrastructure.
If it can execute, it can be exploited.
If it cannot be proven, it cannot be governed.
Shift from Is the model safe? to Is this system authorized to cause this consequence under these exact conditions?
02 · Contents
What the IEG Field Manual contains
Countermeasures
Numbered controls, detection guidance, and remediation playbooks for practitioners.
Evidence artifacts
ExecutionReceipt patterns for proving what executed, under what authority, with what result.
Framework alignment
Cross-walks to MITRE ATLAS, OWASP LLM Top 10, and NIST AI RMF.
03 · Execution stack
Eight layers from input to memory
An apparently minor input or context failure can propagate into tool selection, execution, and persistent memory.
Open the interactive stack04 · Chapter explorer
Index of the field manual
- 01 AI Is Not Software Part 1
- 02 The AI Execution Stack Reference Model Part 1
- 03 Prompt Injection Part 1
- 04 Context Poisoning Part 1
- 05 Reasoning Failures and Goal Hijacking Part 1
- 06 Tool Exploitation Part 1
- 07 Execution Failures and Side Effects Part 1
- 08 Memory Is an Attack Surface Part 1
- 09 Indirect Prompt Injection in the Wild Part 2
- 10 Instruction Smuggling and Hidden Content Part 2
- 11 Retrieval Poisoning and Embedding Weaknesses Part 2
- 12 Cross-Tenant Leakage in RAG and Memory Part 2
05 · Audiences
Built for practitioners who govern execution
Security architects
Map failure pathways across the AI execution stack and prioritize controls that bind inference to authority.
Platform and agent engineers
Treat tool selection, memory, and orchestration as security surfaces, not product features alone.
Risk, compliance, and audit
Demand ExecutionReceipt-grade evidence for consequential AI actions under exact conditions.
Executives and operators
Shift the question from “is the model safe?” to “is this system authorized to cause this consequence?”
06 · Frameworks
Aligned to the references defenders already use
- MITRE ATLAS
- OWASP LLM Top 10
- NIST AI RMF
07 · Open chapter
Chapter 1: AI Is Not Software
Educational and practitioner content is public. Open Chapter 1 with no account, email gate, or unlock step.
Open Chapter10 · Doctrine and enforcement
Read the doctrine. Assess the system. Govern the execution. Prove the decision.
The doctrine is public. Production assessment, integration, enforcement, evidence operations, and enterprise support are delivered by BlockSiFr.
- IEG Field Manual Defines the doctrine
- Protected Actions Consequences that require governance
- CortexTrace Discovers execution activity and evidence
- Execution Exchange Decides allow, constrain, step up, escalate, throttle, deny, or revoke
- ModelMeter Measures computational and business consequence
- FrontDesk Surfaces requests, decisions, approvals, and receipts
Govern what systems may cause.
Free doctrine. Open knowledge. Paid enforcement.