SecureToolKit will be a production-grade Swift library that mediates between untrusted, LLM-generated tool proposals and host-controlled side effects. It exists to make authority explicit, narrow, reviewable, and deterministic.
Its central contract is:
- A model may propose an action.
- A proposal carries no authority.
- SecureToolKit evaluates registered definitions, validated canonical arguments, authenticated intent, provenance, capabilities, and deterministic policy.
- SecureToolKit may deny, require host confirmation, or issue a constrained authorization artifact.
- Only the host application executes, after verifying and atomically consuming that artifact.
- Financial and enterprise applications that expose carefully governed operations to model-assisted interfaces.
- Local AI applications that need a hard boundary between inference and device side effects.
- Security-conscious Swift services and applications that need auditable tool authorization without adopting an agent framework.
- Authority before convenience: missing or ambiguous security state denies.
- Determinism at the boundary: critical allow/deny/escalate decisions are reproducible for the same versioned inputs.
- Least authority: grants are scoped to one subject, tool, canonical argument set, context, lifetime, and consumption.
- Explicit trust: provenance and influence are data, not assumptions.
- Host sovereignty: identity, authentication, confirmation presentation, storage, and execution remain under authenticated host control.
- Portable core: platform-neutral concepts live in the core; Apple-specific mechanisms belong behind adapters.
- Inspectable behavior: decisions and their policy basis are explainable without recording secrets or raw prompts.
SecureToolKit succeeds when an integrating engineer can answer, for every attempted side effect:
- Which registered tool and capabilities were requested?
- What exact canonical arguments were authorized?
- Which authenticated subject and user intent were bound?
- What untrusted influences contributed?
- Which policy version produced the decision?
- Was confirmation required and, if so, what exact challenge was approved?
- When did authority expire, and was it consumed exactly once?
- What privacy-safe audit evidence exists?
SecureToolKit is not responsible for deciding what task a model should pursue, generating plans, invoking models, executing tools, or making a semantic judgment sufficient to authorize an action. Semantic analysis can supply untrusted evidence used to deny or escalate; authenticated host facts and deterministic policy remain the source of authorization.
RC0.1 makes authenticated host facts concrete through an opaque host capability boundary and immutable authority ceilings. It also requires exact schema/tool continuity and derives resource authority from reviewed typed arguments rather than caller assertions.
RC0.2 closes structural composition gaps before confirmation work: proposal assessment and lineage remain continuous, attenuated role authorities share one host domain without entitlement union, policy decisions retain exact policy content, resource-free operations use exact empty authority, authorization ID is independently expected, and validation returns a complete future consumption binding. These are in-memory structural guarantees, not production authenticity, trusted time, durable single use, audit, or execution.