Protected assets include user funds and data, enterprise systems, host credentials, registered tool integrity, policy integrity, authorization artifacts, confirmation integrity, idempotency state, and audit evidence.
The adversary may control model output, prompts, retrieved content, tool output, proposal serialization, timing, retries, and malformed inputs. The adversary may observe or replay artifacts unless a later design protects them. Compromised hosts, executors, policy administrators, adapter implementations, and build systems are outside the principal guarantee, though least-authority contracts should limit damage.
- Description: A user or attacker instructs the model to bypass policy, claim approval, or invoke a protected tool.
- Attack path: Malicious prompt → model emits privileged tool proposal or fabricated authorization claims → naive integration executes.
- Mitigation: Treat all model fields as untrusted; strict validation; authenticated host intent/context; deterministic policy; model claims cannot authorize; exact artifact required by host executor.
- Residual risk: A broadly worded authenticated intent or permissive policy may legitimately authorize a harmful proposal; host intent UX and policy quality remain critical.
- Description: Retrieved documents, web pages, memory, or tool output instruct the model to perform an attacker-chosen action.
- Attack path: Host retrieves attacker content → content influences model → proposal appears responsive to user → protected action requested.
- Mitigation: Record
Influenceand provenance; default absent/unverified provenance to untrusted; policy can deny or require confirmation based on influence; bind action to independently captured intent. - Residual risk: Complete influence tracking is difficult, and a host may omit sources. SecureToolKit cannot detect influences it is not told about; high-risk policy should assume untrusted influence.
- Description: Similar names, metadata, or schemas cause a proposal or reviewer to select the wrong tool.
- Attack path: Model selects confusing identifier → registry resolves loosely or UI shows ambiguous label → wrong operation is authorized.
- Mitigation: Stable typed identifiers and exact versions; collision/confusable rejection; one-definition lookup; confirmation derived from validated definition; authorization binds canonical identity.
- Residual risk: Two intentionally distinct tools may remain semantically confusing to users; registry governance and confirmation UX are host responsibilities.
- Description: A model uses host privileges to perform an action not within the authenticated user's intent or delegated authority.
- Attack path: Untrusted proposal reaches privileged host → host credentials exceed user scope → action executes under host authority.
- Mitigation: Bind authenticated subject, delegated scope, intent, tenant, capabilities, and policy; intersect all authority sources; least-authority adapters; exact executor verification.
- Residual risk: Incorrect host context or overly broad delegation defeats the binding; host authentication and entitlement correctness are assumed.
- Description: Ambiguous encodings, duplicate keys, defaults, nested fields, Unicode, numbers, or alternate representations hide security-relevant arguments.
- Attack path: Proposal passes one parser/policy view → executor interprets a different value → unauthorized effect occurs.
- Mitigation: Strict schema; reject unknown/duplicate/ambiguous content; one versioned canonicalization; bind every argument; executor compares the same canonical request.
- Residual risk: Parser differentials can remain if host execution reconstructs arguments independently; conformance tests and shared canonical bytes are required.
- Description: Tool definition, policy, context, arguments, or protected resource changes after evaluation but before execution.
- Attack path: Safe state is checked → state/version changes → authorization is used under unsafe state.
- Mitigation: Immutable versioned snapshots; exact bindings; short expiry; executor precondition checks; atomic consumption; policy obligations may require resource version/etag binding.
- Residual risk: External resources may not support transactional preconditions. Hosts must choose whether to deny or accept explicitly documented residual races.
- Description: Retries, crashes, concurrency, or ambiguous responses cause one intended operation to execute more than once.
- Attack path: Same logical request submitted concurrently/retried → multiple authorizations or repeated consumption → duplicate side effect.
- Mitigation: Host-generated idempotency identity; single-use authorization; atomic consumption; tool-level idempotency binding; audit correlation.
- Residual risk: Some side effects lack idempotent APIs, and distributed failure may leave outcome unknown. Hosts must reconcile rather than retry blindly.
- Description: A captured approval response or authorization is reused later or in another context.
- Attack path: Attacker captures artifact → resubmits before/after original use or to another tenant/tool.
- Mitigation: Non-reusable challenge identity; subject/context/request binding; finite expiry; atomic one-time consumption; tenant and policy/version binding.
- Residual risk: Single-use depends on durable atomic state or a suitable portable protocol; in-memory tracking alone is insufficient across processes/restarts.
- Description: A caller obtains authority above its authenticated identity, tenant, role, or delegation.
- Attack path: Caller/model asserts stronger identity or scope → permissive merge/default → elevated authorization issued.
- Mitigation: Host-attested
SecurityContext; no model-originated authority; intersection semantics; explicit tenants/delegations; unknown/missing values deny. - Residual risk: Compromised identity provider or incorrect host entitlement data is outside the library's guarantee.
- Description: Requested or granted effects exceed the registered tool definition, intent, policy, or host authority.
- Attack path: Proposal injects capability/constraint → library unions rather than intersects sets → broader grant issued.
- Mitigation: Closed typed capabilities; deterministic intersection; definition maximum; constraint normalization; unknown/incomparable cases deny; exact grant binding.
- Residual risk: Capability taxonomy may be too coarse to express real risk; governance and versioned refinement are needed.
- Description: An authorized request is redirected to a different implementation, version, tenant endpoint, or tool.
- Attack path: Authorization references a name/label → registry or executor resolves it differently → substituted code performs another effect.
- Mitigation: Bind stable tool/definition/schema versions and implementation identity where host policy requires it; immutable registry snapshot; executor exact-match verification.
- Residual risk: SecureToolKit cannot attest deployed executable code by itself. Host supply-chain attestation may be required for high assurance.
- Description: A tool returns hostile instructions, forged facts, secrets, or content intended to authorize a later action.
- Attack path: Tool output is fed to model/context → model treats it as trusted instruction → follow-on proposal gains privileges.
- Mitigation: Tool output remains untrusted provenance unless separately verified; track as
Influence; prevent output from constructing intent/context/approval; minimize audit capture. - Residual risk: Host pipelines may lose provenance or expose secrets to models. Data-flow controls outside SecureToolKit remain necessary.
- Description: Resource exhaustion, pathological nesting, coercion, unsupported versions, or schema features bypass or destabilize validation.
- Attack path: Crafted proposal/schema → parser discrepancy, denial of service, or permissive fallback → policy bypass or outage.
- Mitigation: Authorized immutable schemas; bounded sizes/depth/counts; closed supported feature set; no coercion; deterministic validation; unknown features reject.
- Residual risk: Validation can still consume resources within limits; deployment-level quotas and isolation are required.
- Registry or policy administration compromise can legitimize malicious definitions or rules. Administrative authorization, signing, review, and rollback are later host/design requirements.
- Audit flooding may exhaust storage or hide signals. Rate limits and operational monitoring belong to host deployment without dropping mandatory security transitions silently.
- Sensitive values may leak through errors, metadata, confirmation, or audit. Every display/log contract requires classification and redaction tests.
Phase 3 directly strengthens T-003, T-005, T-006, T-011, and T-013. Exact snapshot/tool/definition/schema bindings prevent canonical substitution. Closed occurrence-preserving objects reject unknown and duplicate fields. Required/optional presence, strict null rejection, exact Int64/UInt64 types, printable-ASCII strings, closed enums, and no coercion eliminate alternate validation views within the supported domain. Tagged lengths, type tags, explicit object order, significant array order, and deterministic limits make canonicalization independent of locale, Unicode normalization, platform formatting, and hash iteration order.
The principal residual risk is before the Phase 3 boundary: a permissive host parser can erase duplicate fields or convert ambiguous numeral text before supplying typed values. SecureToolKit performs no JSON/text parsing and cannot recover discarded evidence. Hosts must preserve field occurrences and exact numeric types, and a later executor must consume the validated canonical meaning rather than reinterpret the original wire request.
| Threat | Phase 4 mitigation | Residual risk |
|---|---|---|
| T-001 Direct prompt injection | Model/proposal data has no path to construct validated intent, context, attestation, or EvaluationInput; structured intent has no semantic-text or wildcard target |
A host that routes model data into authority-sensitive validators defeats the structural boundary; future policy may still be too permissive |
| T-002 Indirect prompt injection | Influence is separate from final provenance and arguments; completeness is explicit per collector boundary; missing coverage remains unknown | The core cannot detect an influence or collection boundary the host entirely omits |
| T-004 Confused deputy | Exact subject, tenant, session state, intent scope, capabilities, resources, renewal, and canonical request must agree | Incorrect host authentication/delegation facts or an overly broad bounded-tool intent remain dangerous |
| T-006 TOCTOU | Intent, context, and attestations carry explicit validity and are rechecked at EvaluationInput construction against explicit time |
Phase 4 has no trusted clock, revocation service, external resource precondition, or authorization-time recheck |
| T-009 Privilege escalation | Host roles are fact-specific; assurance and delegation are attested; subject/tenant/session mismatch rejects | A compromised authority publisher or host integration can supply false structured evidence |
| T-010 Capability escalation | Intended/requested capability sets are nonempty bounded subsets of the exact definition maximum; resources are exact values derived from reviewed typed schema nodes | Final policy and authorization intersections remain required |
| T-012 Malicious tool output | Tool output is a descriptive untrusted provenance/influence source unless exact provenance evidence validates the record; trusted transport does not upgrade content | Future policy must conservatively use trust/completeness, and host pipelines can still lose lineage |
Phase 4 attestations are not cryptographic. hostVerified verifies a bounded
record, not content semantics. No policy enforcement, authorization, trusted
time, or execution protection is claimed.
The bounded typed policy vocabulary reduces T-001/T-002 prompt-injection impact because raw or semantic model output cannot become a predicate or allow source. Exact tool/snapshot predicates and decision binding strengthen T-003/T-011. Exact subject/tenant/session/delegation facts and explicit scope ceilings strengthen T-004/T-009/T-010. Exact immutable input/policy binding reduces T-006 substitution windows, though no trusted time or revocation exists. Provenance and boundary-local influence predicates help contain T-012. Exact resources, bounded trees, and no canonical-byte parsing reduce T-013 schema/resource abuse.
Residual risks remain: a malicious or incorrect administrator can publish unsafe policy; a host can omit an influence boundary, misclassify tool metadata, or supply false time; no policy authenticity, entitlement proof, revocation, authorization, atomic consumption, or execution verification exists in Phase 5.
| Threat | Phase 6 mitigation | Residual risk |
|---|---|---|
| T-003/T-011 tool confusion/substitution | Authorization retains exact canonical request, definition, and complete registry snapshot; validation requires exact host expectations | Structural values are not cryptographically authentic and cannot attest deployed implementation code |
| T-004/T-009 confused deputy/privilege escalation | Subject, tenant, session, delegation, evaluation input, and policy decision are exact repeated bindings | A compromised host or false authenticated context remains outside the guarantee |
| T-006 TOCTOU | Immutable full-value bindings, explicit validation time, and short bounded expiry reject structural/time mutation | External resource state, revocation, trusted time, and atomic execution preconditions do not exist |
| T-007/T-008 duplicate execution/replay | Exact replay and consumption identities plus atomicSingleUseRequired make the host obligation explicit |
No store or consumption exists; repeated validation succeeds and replay remains possible until the host atomically enforces the contract |
| T-010 capability escalation | Issuance recomputes definition ∩ intent ∩ requested ∩ policy; resources use intent ∩ requested ∩ policy; exact equality rejects divergence |
Incorrect broad inputs/policy remain broad within their common intersection |
| T-013 schema/resource abuse | Phase 6 identifiers, scope collections, lifetime, and validation context are closed and bounded | Complete structural snapshots increase artifact size within earlier bounded limits |
| Threat | Added mitigation | Residual risk |
|---|---|---|
| T-004/T-009/T-010 confused deputy and escalation | Immutable host capability/resource ceilings participate in Phase 4, policy, issuance, and validation; the exact opaque host boundary must match | A plugin that obtains the real in-process boundary can exercise its authority |
| T-005/T-013 argument and schema abuse | Reviewed resourceID schema nodes derive policy resources without parsing canonical bytes; requested resources must equal the derived set |
Incorrect schema governance can omit a resource semantic and must be caught in tool review |
| T-003/T-006/T-011 substitution and TOCTOU | Complete schema and snapshot-bound tool-definition values survive Phase 3 through authorization | Structural bindings are not cryptographic authenticity or deployed-code attestation |
| T-010 empty-set escalation | Empty collection-valued predicates reject at policy publication instead of matching through vacuous truth | No residual risk identified in the closed predicate vocabulary |
Phase 6 deliberately does not mitigate tampering by cryptographic means, provide trusted time, store replay state, satisfy confirmation, produce audit evidence, or verify execution. A deployment claiming those properties from Phase 6 alone would be insecure.
Each threat maps to at least one invariant in SECURITY_INVARIANTS.md. Later phase test plans must include malicious inputs, boundary values, concurrency/replay tests, parser differential tests, dependency failures, and executor conformance tests. Passing happy paths is not sufficient.
| Threat | RC0.2 mitigation | Residual risk |
|---|---|---|
| Cross-proposal lineage substitution | Exact assessment, proposal, lineage IDs, and domain persist through authorization | Host collector can omit unseen material; no global completeness |
| Mixed authority domain | Independent proof before policy evaluation and later transitions | Genuine same-process boundary possession remains privileged |
| Role confused deputy | Exact role issuer plus common non-unioned ceiling | Host bootstrap can misassign roles |
| Empty-resource ambiguity | Exact empty sets compose; nonempty canonical resources require matching ceilings | Incorrect schema governance remains possible |
| Observational policy substitution | Complete exact snapshot and policy retained before re-evaluation | No cryptographic authenticity |
| Replay-ID collision | Complete structural future consumption binding | No durable atomic store or collision namespace |
| Boundary allocator reuse | Strong private object retention and === |
No process isolation |
| Ambiguous freshness | Positive bounded maximum age over explicit times | No trusted time or rollback protection |
| Policy resource exhaustion | Aggregate rules/nodes and component limits | Exact comparison remains bounded but nontrivial |