The model proposes. SecureToolKit decides whether the proposal satisfies the security contract. The Host executes.
SecureToolKit is a deterministic Swift 6 authorization and human-confirmation layer for applications that let AI systems propose tool actions. It validates and binds the proposed tool, typed arguments, authenticated intent, provenance, Host authority, policy, scope, and confirmation evidence before a Host may consider execution.
SecureToolKit does not call models or tools. It produces and validates explicit security evidence; the Host remains responsible for authentication, durable single-use Consumption, and every side effect.
Project status: pre-1.0 Phase 7 RC1 candidate. Phases 1–6 have a frozen protocol baseline, and Phase 7 human confirmation is implemented as an RC candidate. This is not production-readiness approval. Trusted time, cryptographic authenticity, durable replay prevention, atomic Consumption, revocation, audit persistence, and Execution remain Host responsibilities or separately approved future work.
The Host is your application: the service, desktop app, command-line tool,
local AI runtime, or other program that integrates SecureToolKitCore. “Host”
does not mean a SecureToolKit server, framework, or hidden runtime.
The Host calls the model, converts a proposed tool call into typed input, supplies authenticated context and trusted facilities, invokes SecureToolKit's public APIs, and decides whether to proceed from Validation to mandatory Consumption and then Execution. SecureToolKit checks and binds evidence; it never takes over the Host or invokes the tool.
| Responsibility | Host application | SecureToolKit |
|---|---|---|
| Model calls and proposal parsing | Calls the model and preserves exact typed input | Performs no model call or text/JSON parsing |
| Authentication | Authenticates people, services, sessions, and administrators | Binds validated Host-supplied identity evidence; authenticates nobody |
| Trusted time | Obtains and protects an appropriate time source | Accepts explicit times and checks deterministic time relationships; reads no clock |
| Tool registry and schema | Reviews tool definitions, metadata, capabilities, and resource semantics | Validates and publishes immutable definitions; resolves exact versions and validates typed arguments |
| Policy | Controls policy administration and supplies the exact policy selection | Validates, publishes, and deterministically evaluates bounded policy |
| Human confirmation | Presents reviewed facts, authenticates the confirmer, and collects an explicit response | Constructs and validates evidence bound to one exact prospective Authorization |
| Authorization evidence | Supplies authenticated inputs, exact snapshots, identities, and explicit times | Constructs scoped, expiring Authorization evidence only after exact checks |
| Validation | Retains independent expectations and supplies the genuine boundary and explicit time | Performs pure, deterministic, non-consuming Validation |
| Replay prevention and Consumption | Atomically records complete single-use Consumption in durable state | Binds replay and Consumption identities; performs no reservation or Consumption |
| Storage | Selects and operates deployment-specific durable storage | Provides no persistence or default storage layer |
| Networking and secrets | Owns network access and protects credentials and keys | Performs no networking and provides no secret store |
| Audit sinks | Operates any required durable, access-controlled audit facility | Provides no durable audit sink |
| Execution | Invokes the side-effecting tool only after required Consumption succeeds | Provides no executor and performs no side effect |
In this repository, Authorization is controlled evidence, Validation is a pure check of that evidence, Consumption is the Host's durable atomic single-use act, and Execution is the Host-owned tool side effect. None of the first three silently performs the next.
Language models are good at proposing actions, but a plausible model response is not proof of identity, intent, authority, policy compliance, or human consent. Prompt injection, retrieved documents, prior tool output, and model hallucinations can all influence a proposal.
SecureToolKit exists to make the boundary between untrusted AI output and trusted Host authority explicit, deterministic, reviewable, and fail closed.
Tool-using AI applications must answer more than “is this user allowed?” They must establish exactly:
- which reviewed tool and version was proposed;
- whether its arguments satisfy a closed schema and canonical representation;
- which authenticated subject, tenant, session, and delegation are bound;
- what provenance and outside influences contributed to the proposal;
- whether fixed policy permits, denies, or requires confirmation;
- which capabilities and resources remain after intersection-only constraints;
- whether confirmation covered this exact operation; and
- whether the resulting evidence is current and unchanged.
SecureToolKit provides those structural checks without turning model output, policy output, confirmation, or Validation into Execution authority.
Use SecureToolKit when AI-generated tool proposals may lead to meaningful real-world side effects and the Host must retain the final security decision. Typical domains include:
- financial systems and payment workflows;
- cloud administration and infrastructure automation;
- healthcare operations;
- industrial control;
- enterprise approval workflows;
- developer tooling that can modify code or environments;
- robotics and device control; and
- local AI applications with access to sensitive files or system tools.
It is a good fit whenever the integration rule is:
The model proposes.
The Host must decide.
The Host executes.
SecureToolKit helps the Host make that decision from explicit, immutable, bounded evidence rather than model confidence or free-form text.
SecureToolKit is not useful as a replacement for:
- a simple chatbot with no side-effecting tools;
- an LLM wrapper or prompt library;
- a model-provider SDK;
- a tool execution engine;
- a workflow automation framework; or
- an agent framework that plans, loops, or selects tools.
It complements those systems when they need a separate authorization boundary. It does not provide model access, orchestration, UI, networking, storage, deployment, or an executor.
Traditional authorization usually begins with an authenticated principal and a known operation. SecureToolKit addresses the earlier AI-specific boundary: identifying and binding the exact operation proposed through untrusted model output. It complements IAM, OAuth, RBAC, and ABAC; it does not replace them.
Agent frameworks plan work, call models, select tools, maintain loops, and may execute actions. SecureToolKit does none of those things. A model proposal is only untrusted input to its security pipeline.
Model SDKs provide inference APIs, streaming, tool-call representations, and provider integration. SecureToolKit is provider-neutral and performs no model call or network request.
Tool runners dispatch functions and produce side effects. SecureToolKit has no executor. Successful Validation remains non-consuming evidence; the Host must atomically consume the Authorization identity before invoking its own runner.
flowchart TD
M["Model\nproposes an untrusted action"]
S["SecureToolKit\nvalidates, evaluates, and binds evidence"]
H["Host\nsupplies authority and consumes once"]
E["Execution\nside effect outside SecureToolKit"]
M --> S --> H --> E
That separation is the project:
- Model: proposes tools and arguments but never grants authority.
- SecureToolKit: validates exact inputs, evaluates deterministic policy, constructs controlled evidence, and validates it without consuming it.
- Host: owns authentication, trusted facilities, atomic single use, and the decision to proceed.
- Execution: always occurs outside SecureToolKit.
| Area | What the library provides |
|---|---|
| Tool registry | Exact tool/version lookup, immutable snapshots, lifecycle rules, bounded metadata and capabilities |
| Schema validation | Closed typed schemas, unknown/duplicate rejection, deterministic canonical request bytes |
| Intent and provenance | Authenticated intent, explicit provenance and influence completeness, exact Host-boundary binding |
| Policy | Bounded immutable policies, deterministic precedence, fail-closed decisions, intersection-only scope |
| Authorization | Scoped, expiring evidence bound to identity, tool, policy, request, Host authority, and replay identities |
| Human confirmation | Explicit affirmative evidence bound to reviewed presentation facts and one prospective Authorization |
| Validation | Pure, deterministic, repeatable reconstruction against independently retained expectations |
Requirements:
- Swift 6.0 or newer
- Swift Package Manager
- Python 3 for structural contract checks
Validate a checkout:
swift package describe
swift build
swift test
swift format lint --recursive --strict Package.swift Sources Tests
python3 Scripts/check_phase1_structure.py
python3 Scripts/check_phase2_structure.py
python3 Scripts/check_phase3_structure.py
python3 Scripts/check_phase4_structure.py
python3 Scripts/check_phase5_structure.py
python3 Scripts/check_phase6_structure.pyUntil an immutable public release tag and repository URL exist, evaluate the package through a local SwiftPM dependency:
dependencies: [
.package(path: "../SecureToolKit")
]Add the SecureToolKitCore product to the consuming target, then follow the
Examples. The examples use public APIs but are
explanatory fragments, not production Host implementations.
SecureToolKit/
├── Sources/SecureToolKitCore/ # Platform-neutral library
├── Tests/SecureToolKitTesting/ # Deterministic positive and negative tests
├── Scripts/ # Structural contract checks
├── Examples/ # Non-normative Host integration guides
├── docs/ # Protocol, ADRs, contracts, reviews, and evidence
├── .github/ # CI and contribution templates
├── Package.swift
└── README.md
The official Examples package provides a recommended learning order:
- Policy Evaluation
- Host Boundary
- Basic Authorization
- Human Confirmation
- Validation
- Threat Model walkthrough
Every guide explains the problem, why the flow exists, expected lifecycle, threats prevented, common mistakes, and related documentation. Examples never grant authority, consume an Authorization, or execute a tool.
Start with the documentation index.
- Vision
- Architecture
- Security model
- Threat model
- Security invariants
- Public API philosophy
- Frozen Phase 1–6 protocol
- Phase 7 architecture
- Phase 7 implementation contract
- Architecture decisions
- FAQ
Normative protocol and accepted ADRs take precedence over examples, plans, release notes, and operational evidence.
See ROADMAP.md for current status and scope boundaries. Phase 8 has not begun, and public repository preparation does not start it.
Read CONTRIBUTING.md before proposing a change. Participation is governed by the Code of Conduct, and general questions follow SUPPORT.md.
Read SECURITY.md before reporting a vulnerability. Do not post exploit details, credentials, customer data, raw prompts, or sensitive tool arguments in a public issue.
SecureToolKit is not a complete production authorization deployment. Hosts must provide and protect authentication, trusted time, cryptographic authenticity where required, durable replay handling, atomic Consumption, revocation, audit persistence, secrets, and Execution.
SecureToolKit is available under the Apache License 2.0. The license choice is recorded in ADR-0011.