Agentic Safe Access
UnoLock was built to protect you. Now it can protect both you and your agent.
Agentic Safe Access is currently in alpha. It is an upcoming UnoLock capability for AI agents, available now for evaluation and early testing, but not ready for broad production use yet.
Overview
Agentic Safe Access lets a Safe admin create a dedicated UnoLock access key for an AI agent. This allows an agent to connect to an existing Safe through the UnoLock MCP while preserving the same core zero-knowledge model used for normal access keys.
Agent keys are intended for:
- AI assistants that need controlled access to selected Safe data
- automation that must work within strict Safe and Space permissions
- customer-controlled agent workflows where the user remains in control of registration and PIN entry
Agentic Safe Access does not let an agent create a Safe. A human user still creates the Safe and creates the agent key.
Why Customers Want This
Agentic Safe Access is useful for more than secret injection.
It lets customers use UnoLock as a safer place for:
- agent memory
- notes the agent reads and updates
- checklists and task state
- structured working data
- secrets that should not live in plaintext local files
That means UnoLock can help protect both:
- the user, by limiting what the agent can access
- the agent, by keeping its important data and secrets in a durable encrypted Safe instead of a fragile local file or ad hoc memory store
Tier Requirement
Agentic Safe Access now has two practical paths:
- Free and Inheritance can share their single included Safe space with one extra Agent Key
- Sovereign and HighRisk are still the right tiers for broader multi-Space and collaboration-heavy agent workflows
That means:
- a Free Safe can add one Agent Key for its single included space, but it still cannot add extra regular keys or extra Spaces
- an Inheritance Safe can also add one Agent Key for its single included space
- if the user wants broader Space segmentation, Shared Space collaboration, or larger operational setups, they should use Sovereign
Why TPM or Secure Enclave Matters
Agentic Safe Access is meant for the highest-security AI access model UnoLock can reasonably provide.
For normal customer use, the agent host should provide:
- TPM
- vTPM
- Secure Enclave
- or another platform-backed non-exportable key store
If the UnoLock Agent MCP cannot find a production-ready provider, it can still fall back to a lower-assurance software provider. When that happens, the MCP reports the reduced assurance clearly instead of pretending the host met UnoLock’s preferred storage requirements.
That is intentional. The goal is to keep agent access as device-bound and resistant to secret export as the host allows, not to reduce Safe access to a reusable password, file key, or API token without warning.
Best Fit Environments
Agentic Safe Access is a better fit for user-adjacent AI agents than for arbitrary unattended infrastructure.
Best fit:
- local desktop AI assistants
- MCP hosts running in a normal logged-in user session
- user-controlled machines and VMs with TPM or vTPM access
- Windows and WSL hosts that can use either TPM-backed keys or a non-exportable Windows CNG fallback
On macOS, the UnoLock Agent MCP now prefers Secure Enclave and falls back to a non-exportable Keychain-backed key when Secure Enclave is unreliable in the current launch context. The overall macOS path is still alpha, but it no longer depends entirely on Secure Enclave working cleanly.
More difficult environments:
- fully headless background agents
- remote sandboxes
- plain containers without hardware-backed key access
- environments where the operator cannot reliably expose a login keychain, TPM, or vTPM to the agent process
This is not a limitation of UnoLock’s permission model. It is a consequence of trying to keep AI access device-bound and high-security in environments that may not be able to provide strong non-exportable key storage.
The official UnoLock Agent is available at:
https://github.com/TechSologic/unolock-agenthttps://github.com/TechSologic/unolock-agent/releases
Get Started
If you want to use Agentic Safe Access:
- Decide whether you need:
- a simple single-space agent setup on Free or Inheritance
- or broader multi-Space segmentation on Sovereign
- Install the UnoLock Agent MCP from the official GitHub Releases page when a platform binary is available, or from the official GitHub repository as the source-install fallback.
- Create an Agent Key in the UnoLock client.
- Give the generated
#/agent-register/...connection URL to your AI host. - Follow Connect an AI Agent to a Safe for the full setup flow.
For end-user documentation, see:
In the normal hosted UnoLock setup, the MCP does not need special UnoLock-specific configuration ahead of time. It can derive what it needs from the Agent Key connection URL.
How It Works
- A Safe admin creates a dedicated Agent Key in the UnoLock client.
- The admin assigns that key:
- a name
- a permission level such as
roorrw - optional Space restrictions
- UnoLock generates a one-time agent key connection URL.
- The user gives that URL to the AI host using the UnoLock MCP.
- The MCP registers a device-bound credential on the agent host.
- On later startups, the agent re-authenticates with that credential and, if configured, asks the user for the agent PIN.
Security Model
Agentic Safe Access is designed to stay as close as possible to UnoLock’s normal access-key model:
- Zero-knowledge: the server stores wrapped key material, not plaintext Safe secrets
- Device-bound authentication: the MCP uses TPM, vTPM, Secure Enclave, or platform key storage for normal customer use
- One-time registration URL: the connection URL is for enrollment only and cannot be reused after successful registration
- PIN protection: the agent can require a PIN on each authentication, and the MCP sends only a challenge-bound hash rather than the raw PIN
- Same Safe ACL model: agent keys use the same access model as other delegated device keys, including
ro,rw, and Space restrictions
Device Assurance Information
UnoLock can show device assurance information for Agent Keys and other device keys in the key-management UI.
This information is:
- reported by the client that performed the registration
- intended to help the Safe owner understand what kind of host or authenticator was used
- useful for comparing a TPM-backed agent host, a vTPM-backed host, and a normal WebAuthn device
This information is not:
- independently verified by UnoLock
- a server-side attestation policy decision
- a guarantee that the host is trustworthy
Treat the assurance view as client-reported diagnostic and security context, not as an authoritative certification.
Permissions
Agent keys are normal UnoLock device access keys with agent-specific registration and authentication behavior layered on top.
That means:
- an agent key can be limited to selected Spaces
- a read-only agent key can see only the Spaces and records granted to it
- a read-write agent key can create and update only the records allowed by its granted Spaces and record lock state
- agent keys are limited to
roorrw; they are not allowed to haveadmin
This follows the same access model described in Access Keys & Safe Access.
User Experience
From the user’s perspective, the flow is:
- Create an Agent Key in UnoLock.
- Give the generated agent key connection URL to the AI host.
- If the key uses a PIN, it is usually best to give the AI host the connection URL and the PIN at the same time.
- The agent can then read the Safe data allowed by that key, and if the key is
rw, it can also perform the supported record writes within those permissions.
If the MCP restarts later:
- the agent remains registered
- the PIN is not kept in memory
- the agent asks the user for the PIN again before re-authenticating
Treat the Agent Key connection URL as one-time setup input. If registration has already advanced on the Safe and then fails, for example because the PIN was wrong, generate a fresh Agent Key URL before retrying.
Current Scope
The current customer-facing MCP slice supports:
- listing visible Spaces
- listing notes
- listing checklists
- retrieving individual records in an agent-friendly format
- listing Cloud files in the current Space
- downloading a Cloud file by exact file name or archive id in the current Space
- creating notes
- updating note text
- renaming notes and checklists
- creating checklists
- toggling checklist item state
- adding checklist items
- removing checklist items
- uploading, renaming, replacing, and deleting Cloud files
- narrow one-way file backup through the current sync feature, with explicit restore
The current write MVP is still intentionally narrow:
- writes are limited to notes and checklists stored in UnoLock Records archives
- existing record updates require the latest
version - locked/read-only records cannot be modified
- Cloud file operations are limited to UnoLock Cloud archives, not Local or Msg archives
- file uploads use the current Space and require explicit force when a same-name Cloud file already exists in that Space
- file download by exact name stays Space-scoped and now hints when the target may be in a different accessible Space
Why It Matters
This feature gives customers a way to use UnoLock as a secure memory and secret store for AI agents without turning Safe access into a reusable API-key or password model.
It keeps the main UnoLock principles intact:
- customer-controlled access
- strong cryptographic authentication
- Space-scoped permissions
- zero-knowledge storage
- durable encrypted storage for agent data that should survive beyond one local process or machine
FAQs
Can an AI agent create a Safe?
No. A human user must create the Safe first. Agent keys are for registering and accessing an existing Safe.
Can an agent be limited to one Space?
Yes. On Free and Inheritance, that means the single included Safe space. On Sovereign and higher tiers, the key can be restricted to selected Spaces.
Can an agent modify notes and checklists?
Yes, if the Agent Key has rw access to that Space and the target record is not locked. The current write MVP supports note create/update, checklist create, checklist item state changes, checklist item add/remove, and title rename.
Does the server see the agent bootstrap secret or PIN?
No. The one-time bootstrap material is client-side only, and the agent PIN is sent as a challenge-bound hash rather than a raw PIN value.
Does the MCP have to stay running forever?
No. The agent stays registered across restarts. After restart, the agent re-authenticates and asks for the PIN again if needed.
What does the Device Assurance view mean?
It shows device and registration details reported by the registering client. It is useful context for the Safe owner, but UnoLock does not independently verify those claims.
Integration with Other Features
- Access Keys & Safe Access: agent keys use the same Safe access model
- Biometric and FIDO2 Access: human access still uses WebAuthn-style authenticators, while agent access uses device-bound host credentials
- PIN Code: agent PIN protection preserves the owner-consent part of the access model
- Spaces: agent keys can be restricted to selected Spaces
- Connect an AI Agent to a Safe: step-by-step setup guide for customers