billmedj/accordlock

A desktop AI agent that checks actions against an approved task. Built on Goose.

Rust

0

41 commits

updated Sep 10, 2026

See the code
agentic-ai
ai-agents
ai-security
desktop-app
devsecops
execution-security
formal-methods
goose
kubernetes
lean4
llm-security
policy-enforcement
rust
tla-plus
zero-trust

README

AccordLock

A desktop AI agent that checks actions against an approved task.

Based on Goose, with a Rust runtime for protected file, command and network operations.

Source CI

Engineering alpha. For local evaluation. Production deployment has not been validated, and signed installers are not available.

Run the demo | Desktop source | Current status | Roadmap

Try it without a model

From the repository root:

python scripts/run_demo.py --display markdown

Requires Python 3.11+, the pinned Rust toolchain, and C++ build tools on Windows. The demo builds native programs and tests five cases: protected files, blocked domains, action-bound approval, single-use grants and stale authority.

PASS provider_free_demo cases=5 provider=NONE network=NOT_ATTEMPTED

No model or cloud account is needed. The cases make no external requests. See the demo guide for offline mode and expected results.

What you can use

AreaAvailable in this source
DesktopProjects, tasks, model connections, approvals and settings
Files and commandsScoped access, change previews, recoverable file deletion and configured executable access
NetworkHTTPS GET and HEAD on exact configured public domains
AuditAction history, integrity checks, search, JSON/Markdown export, revocation and supported file recovery
Cloud preflightRead-only GitHub, ECR, EKS and Kubernetes observations with signed receipts; real-account validation remains
Remote approvalsLocal protocol foundations for Slack, Teams, Telegram and WhatsApp; live gateways still need validation

Provider and model compatibility varies. File recovery covers supported operations; it cannot undo every external action.

How actions are checked

The agent proposes an action. The runtime checks its task permissions, relevant state and expiry. An allowed action receives a single-use grant. A broker consumes that grant before attempting the action and records the result.

The approved task and proposed action enter AccordLock. Checks return allow, approval required or deny. Allowed actions run through a broker.

Changing a bound target or argument invalidates the authorization. Consumed grants cannot be reused. When a broker cannot confirm the result, it records UNKNOWN; that outcome requires reconciliation before another attempt.

These controls apply to supported actions routed through the brokers. Untrusted content cannot grant extra permissions on those paths. Actions that bypass the runtime are outside its protection.

The desktop's free-text intent check currently shows Not verified: it has no qualified production evidence provider. Structural task permissions still apply. An allowed action is not proof that the model understood the request.

See the architecture and threat model.

Tests and formal models

This snapshot includes 81 Lean theorems over selected abstract authorization properties, eight bounded TLA+ models and 73 AccordBench cases. Ten assurance claims link models to source and tests.

python assurance/verify.py --root runtime --json
python -m unittest discover -s assurance/tests -t assurance -v

The models do not prove the complete Rust implementation or a production deployment. Read the assurance contract and local validation record for scope and results.

Whence informs the treatment of configuration provenance and stale authority. Research provenance explains that connection.

ETP defines separate, product-neutral records for action authorization and outcomes. Native ETP mediation is planned.

Before production use

Clean-checkout desktop validation, signed installation and updates, retained cloud and messaging tests, and an independent security review remain open. See known limitations.

Source and license

The desktop, runtime and assurance tools are included here. Source provenance records the published snapshot.

Apache-2.0, with attribution in NOTICE and third-party notices. Read CONTRIBUTING.md before changing an enforcement path. Report vulnerabilities through SECURITY.md.

Visual identity | Writing rules

Contributors

billmedj

41 commits

billmedj/accordlock

A desktop AI agent that checks actions against an approved task. Built on Goose.

Rust

0

41 commits

updated Sep 10, 2026

See the code
agentic-ai
ai-agents
ai-security
desktop-app
devsecops
execution-security
formal-methods
goose
kubernetes
lean4
llm-security
policy-enforcement
rust
tla-plus
zero-trust

README

AccordLock

A desktop AI agent that checks actions against an approved task.

Based on Goose, with a Rust runtime for protected file, command and network operations.

Source CI

Engineering alpha. For local evaluation. Production deployment has not been validated, and signed installers are not available.

Run the demo | Desktop source | Current status | Roadmap

Try it without a model

From the repository root:

python scripts/run_demo.py --display markdown

Requires Python 3.11+, the pinned Rust toolchain, and C++ build tools on Windows. The demo builds native programs and tests five cases: protected files, blocked domains, action-bound approval, single-use grants and stale authority.

PASS provider_free_demo cases=5 provider=NONE network=NOT_ATTEMPTED

No model or cloud account is needed. The cases make no external requests. See the demo guide for offline mode and expected results.

What you can use

AreaAvailable in this source
DesktopProjects, tasks, model connections, approvals and settings
Files and commandsScoped access, change previews, recoverable file deletion and configured executable access
NetworkHTTPS GET and HEAD on exact configured public domains
AuditAction history, integrity checks, search, JSON/Markdown export, revocation and supported file recovery
Cloud preflightRead-only GitHub, ECR, EKS and Kubernetes observations with signed receipts; real-account validation remains
Remote approvalsLocal protocol foundations for Slack, Teams, Telegram and WhatsApp; live gateways still need validation

Provider and model compatibility varies. File recovery covers supported operations; it cannot undo every external action.

How actions are checked

The agent proposes an action. The runtime checks its task permissions, relevant state and expiry. An allowed action receives a single-use grant. A broker consumes that grant before attempting the action and records the result.

The approved task and proposed action enter AccordLock. Checks return allow, approval required or deny. Allowed actions run through a broker.

Changing a bound target or argument invalidates the authorization. Consumed grants cannot be reused. When a broker cannot confirm the result, it records UNKNOWN; that outcome requires reconciliation before another attempt.

These controls apply to supported actions routed through the brokers. Untrusted content cannot grant extra permissions on those paths. Actions that bypass the runtime are outside its protection.

The desktop's free-text intent check currently shows Not verified: it has no qualified production evidence provider. Structural task permissions still apply. An allowed action is not proof that the model understood the request.

See the architecture and threat model.

Tests and formal models

This snapshot includes 81 Lean theorems over selected abstract authorization properties, eight bounded TLA+ models and 73 AccordBench cases. Ten assurance claims link models to source and tests.

python assurance/verify.py --root runtime --json
python -m unittest discover -s assurance/tests -t assurance -v

The models do not prove the complete Rust implementation or a production deployment. Read the assurance contract and local validation record for scope and results.

Whence informs the treatment of configuration provenance and stale authority. Research provenance explains that connection.

ETP defines separate, product-neutral records for action authorization and outcomes. Native ETP mediation is planned.

Before production use

Clean-checkout desktop validation, signed installation and updates, retained cloud and messaging tests, and an independent security review remain open. See known limitations.

Source and license

The desktop, runtime and assurance tools are included here. Source provenance records the published snapshot.

Apache-2.0, with attribution in NOTICE and third-party notices. Read CONTRIBUTING.md before changing an enforcement path. Report vulnerabilities through SECURITY.md.

Visual identity | Writing rules

Contributors

billmedj

41 commits

Languages

Rust

69.0%

TypeScript

21.8%

Python

3.6%

TLA

1.2%

PLpgSQL

1.0%