Threat model

A protocol that authorizes real-world action must publish what it defends against. This document is the public threat model — what we considered, what we mitigate, what's residual risk you should be aware of.

Threats

T1 — Compromised LLM injects a malicious intent

Scenario: an attacker controls part of the prompt path and convinces the LLM to emit an intent the user did not authorize.

Mitigations:

Every action is bounded by a delegation token the LLM does not control.
The Authorization Boundary blocks any action outside the delegation's scope.
Multi-party approval chains require human signature for high-stakes actions.

Residual risk: if the malicious intent fits within the delegation scope, the protocol cannot distinguish it from a legitimate intent. Defense-in-depth: narrow delegations, hard-deny lists, monitoring on the action stream.

T2 — Compromised SDK or client leaks a delegation token

Scenario: an attacker exfiltrates a delegation token (e.g. via a supply-chain compromise of an SDK or via a logging accident on the client).

Mitigations:

Delegation tokens are single-use within their TTL.
Tokens carry an explicit TTL (typically minutes-to-hours, not weeks).
Revocation takes effect at the next boundary evaluation.
Replay of a token outside its TTL is rejected.

Residual risk: a token can still be used during its TTL if the attacker acts faster than the legitimate caller. Defense-in-depth: short TTLs, rotate on suspicion.

T3 — Replay attack on a signed receipt

Scenario: an attacker captures a signed receipt and re-presents it as proof of a fresh action.

Mitigations:

Receipts include a created timestamp.
Verifiers SHOULD reject receipts with timestamps outside their freshness window (recommended: 5 minutes).
Receipts include a unique transactionId — replays show duplicate ids.

Residual risk: if the verifier has no freshness check, a stale receipt verifies. The verification API includes a recommended-freshness check that's opt-in.

T4 — Privilege escalation through delegation chains

Scenario: an agent uses a low-spend delegation to act, then chains its output into a higher-spend delegation belonging to another agent.

Mitigations:

Each action is evaluated against its own delegation only — chaining is explicit, not implicit.
Multi-party approval requires named approvers for cross-delegation actions.
The audit log records the full delegation chain per action.

Residual risk: if approvers blanket-approve without reviewing, the chain collapses to whoever approved last. Mitigate via approver training and out-of-band review.

T5 — Side-channel attack on the Authorization Boundary

Scenario: an attacker times boundary responses to learn which rules fired, inferring policy structure.

Mitigations:

Block responses include the failing rule explicitly — rule disclosure is by design, not a side channel.
Internal rule order is not exposed; only the failing rule is named.
Side-channel resistance properties for the boundary will be specified in the production gateway's security posture once measured.

Residual risk: rule names are exposed to the caller. Treat rule names as non-secret; encode actual policy logic in rule predicates, not rule names.

T6 — Adversarial prompt injection through structured fields

Scenario: a user-controlled string passes through the agent into an intent field and contains instructions that attempt to alter downstream evaluation.

Mitigations:

The boundary evaluates intents as structured data, not as prompts.
String fields are not interpreted as instructions by the boundary or the scoring engine.
Intent fields go through schema validation before any evaluation.

Residual risk: if the target system (the thing being acted on) interprets strings as commands, that's outside our scope. Use parameterized APIs at the target.

T7 — Insider threat in approval chains

Scenario: a named approver is malicious or compromised and approves an action they shouldn't.

Mitigations:

Multi-party approval (k-of-n) for high-stakes actions.
Approvals are signed and traceable to the named approver.
Audit log records every approval with timestamp + signature.

Residual risk: k-of-n only works if the n approvers are independent. Same team, same vendor, etc. — the n approvers can collude.

T8 — Quantum threat to cryptographic primitives

Scenario: large-scale quantum computers break current ECDSA-class signature schemes and SHA-2 hash families.

Mitigations:

Receipts include algorithm field — old receipts can be re-validated under quantum-resistant schemes when those mature.
The signing key registry supports algorithm-tagged keys.
We track NIST PQC standardization and will migrate when standards land.

Residual risk: receipts signed today may not be verifiable in a post-quantum world. For long-term archival, plan to re-sign with PQ algorithms when available.

Reporting

Discovered something not covered here? We pay for valid reports.

security@executionprotocol.dev (PGP key on the security page)

Threat model

Threats

T1 — Compromised LLM injects a malicious intent

Scenario: an attacker controls part of the prompt path and convinces the LLM to emit an intent the user did not authorize.

Mitigations:

Every action is bounded by a delegation token the LLM does not control.
The Authorization Boundary blocks any action outside the delegation's scope.
Multi-party approval chains require human signature for high-stakes actions.

T2 — Compromised SDK or client leaks a delegation token

Scenario: an attacker exfiltrates a delegation token (e.g. via a supply-chain compromise of an SDK or via a logging accident on the client).

Mitigations:

Delegation tokens are single-use within their TTL.
Tokens carry an explicit TTL (typically minutes-to-hours, not weeks).
Revocation takes effect at the next boundary evaluation.
Replay of a token outside its TTL is rejected.

Residual risk: a token can still be used during its TTL if the attacker acts faster than the legitimate caller. Defense-in-depth: short TTLs, rotate on suspicion.

T3 — Replay attack on a signed receipt

Scenario: an attacker captures a signed receipt and re-presents it as proof of a fresh action.

Mitigations:

Receipts include a created timestamp.
Verifiers SHOULD reject receipts with timestamps outside their freshness window (recommended: 5 minutes).
Receipts include a unique transactionId — replays show duplicate ids.

Residual risk: if the verifier has no freshness check, a stale receipt verifies. The verification API includes a recommended-freshness check that's opt-in.

T4 — Privilege escalation through delegation chains

Scenario: an agent uses a low-spend delegation to act, then chains its output into a higher-spend delegation belonging to another agent.

Mitigations:

Each action is evaluated against its own delegation only — chaining is explicit, not implicit.
Multi-party approval requires named approvers for cross-delegation actions.
The audit log records the full delegation chain per action.

Residual risk: if approvers blanket-approve without reviewing, the chain collapses to whoever approved last. Mitigate via approver training and out-of-band review.

T5 — Side-channel attack on the Authorization Boundary

Scenario: an attacker times boundary responses to learn which rules fired, inferring policy structure.

Mitigations:

Block responses include the failing rule explicitly — rule disclosure is by design, not a side channel.
Internal rule order is not exposed; only the failing rule is named.
Side-channel resistance properties for the boundary will be specified in the production gateway's security posture once measured.

Residual risk: rule names are exposed to the caller. Treat rule names as non-secret; encode actual policy logic in rule predicates, not rule names.

T6 — Adversarial prompt injection through structured fields

Scenario: a user-controlled string passes through the agent into an intent field and contains instructions that attempt to alter downstream evaluation.

Mitigations:

The boundary evaluates intents as structured data, not as prompts.
String fields are not interpreted as instructions by the boundary or the scoring engine.
Intent fields go through schema validation before any evaluation.

Residual risk: if the target system (the thing being acted on) interprets strings as commands, that's outside our scope. Use parameterized APIs at the target.

T7 — Insider threat in approval chains

Scenario: a named approver is malicious or compromised and approves an action they shouldn't.

Mitigations:

Multi-party approval (k-of-n) for high-stakes actions.
Approvals are signed and traceable to the named approver.
Audit log records every approval with timestamp + signature.

Residual risk: k-of-n only works if the n approvers are independent. Same team, same vendor, etc. — the n approvers can collude.

T8 — Quantum threat to cryptographic primitives

Scenario: large-scale quantum computers break current ECDSA-class signature schemes and SHA-2 hash families.

Mitigations:

Receipts include algorithm field — old receipts can be re-validated under quantum-resistant schemes when those mature.
The signing key registry supports algorithm-tagged keys.
We track NIST PQC standardization and will migrate when standards land.

Residual risk: receipts signed today may not be verifiable in a post-quantum world. For long-term archival, plan to re-sign with PQ algorithms when available.

Reporting

Discovered something not covered here? We pay for valid reports.

security@executionprotocol.dev (PGP key on the security page)

Threat model

Threats

T1 — Compromised LLM injects a malicious intent

T2 — Compromised SDK or client leaks a delegation token

T3 — Replay attack on a signed receipt

T4 — Privilege escalation through delegation chains

T5 — Side-channel attack on the Authorization Boundary

T6 — Adversarial prompt injection through structured fields

T7 — Insider threat in approval chains

T8 — Quantum threat to cryptographic primitives

Reporting

See also

Threat model

Threats

T1 — Compromised LLM injects a malicious intent

T2 — Compromised SDK or client leaks a delegation token

T3 — Replay attack on a signed receipt

T4 — Privilege escalation through delegation chains

T5 — Side-channel attack on the Authorization Boundary

T6 — Adversarial prompt injection through structured fields

T7 — Insider threat in approval chains

T8 — Quantum threat to cryptographic primitives

Reporting

See also