Architecture

Documentation Map

• Overview

• Quick Start

• Installation

• Configuration

• Operations

• Troubleshooting

• Release Notes

• Compatibility

• Architecture

• Security

• Integrations

• Capabilities

• Roadmap

• OSS Inventory

• Channel: stable

• Source repo: JaddaHelpifyr/jhf-keystore

Architecture

Access model

This repository carries the canonical access-model documentation in ACCESS_MODEL.md (docs/ACCESS_MODEL.md) and the checked-in contract files under ../contracts (contracts).

The access model is deliberately business-readable and repository-readable at the same time:

• jhf-heddle is the future SSO and claim source
• jhf-fabric is the policy and entitlement truth source
• jhf-deployment materializes Vaultwarden state
• jhf-keystore remains the local consumer and verifier

The repo itself does not create users, groups, or collections. It only documents and consumes the projection that other repos or operators materialize.

Zielbild

Vaultwarden Host
  -> menschlicher Zugriff uber Browser / Cloudflare
  -> Organization: Helpifyr KeyStore
  -> Shared-Collections + Agent-Collections

OpenClaw Host
  -> lokaler bw Login oder lokales bw serve
  -> jhf-keystore Skill
  -> OpenClaw exec SecretRefs

Write path
  -> Agent Request
  -> n8n Policy Checks
  -> Human Approval
  -> Vaultwarden Update

Read Path

1. OpenClaw fordert ein Secret uber source: exec an.
2. scripts/run.sh resolve ... ruft die Python-CLI auf.
3. Die CLI nutzt standardmassig bw get item ....
4. Optional kann VW_PROVIDER=serve gesetzt werden.
5. In serve-Mode wird nur eine lokale URL akzeptiert.
6. Das Secret wird nur fur den jeweiligen Agent-Kontext aufgelost.

Write Path

1. Ein Agent oder ein System beantragt eine Anderung.
2. n8n validiert Agent-ID, Item-Namen, Ziel-Collection und Operationstyp.
3. Human Approval entscheidet approve oder deny.
4. Erst danach erfolgt der technische Write nach Vaultwarden.
5. Audit-Daten werden ausserhalb des Repositories dokumentiert.

Collection-Modell

Empfohlen wird:

• shared/providers
• shared/infrastructure-readonly
• genau eine Collection agents/<agent-id> pro Agent

Das ist absichtlich nicht dasselbe wie "ein grosser gemeinsamer Vault fur alle", weil dadurch Least Privilege erhalten bleibt.

Warum exec fur OpenClaw?

• keine offene Read-API fur Agents notig
• keine Secret-Werte in .env
• besser pro Agent trennbar
• lokal besser auditierbar
• sauberer Migrationspfad von .env zu per-Agent-Secrets