Credentials and who can use them

When you connect an account to Lowkey — a mailbox, an API key, a signing key — the secret goes into the box’s vault. Agents never see it. They ask the daemon to use it, and the daemon makes the request on their behalf.

A vaulted credential belongs to one person. Being in the same project, talking to the same agent, or sitting in the same conversation doesn’t let someone else use your mailbox. If you want a teammate to use it, you say so explicitly, for one operation at a time.

This page is about credentials. Sharing a project is a different thing and works differently — see Working with other people.

Your credentials, in Vault settings

Open Settings → Vault. You’ll see the credentials you own and the ones people have shared with you. Pick one and its access panel shows:

• who owns it,
• who else may use it, for which operations, in which projects,
• which scheduled jobs are approved,
• which approvals are currently remembered, and
• how strongly the box is enforcing all of this.

There is never a “show the secret” button. Nobody — including you, including an admin — reads the value back out of the vault through Lowkey.

The per-person rules on this page apply to a credential once it has been protected — a deliberate step, taken by its owner or by whoever runs the box. A protected credential starts out owner-only, and stays that way until you share it. Accounts nobody has protected yet keep behaving the way they always have. Ownership is never guessed from where a credential happens to live, so nothing gets opened up or shut off behind your back. Protecting a credential, like every other change on this page, is something you do while signed in — an agent can walk you to it, but it can’t do it for you.

An owner can replace their own operation, project, and tool scope; doing so ends their prior remembered and ongoing approvals without changing anyone else’s share.

Sharing one operation with one person

Say Jordan connected a mailbox and wants Priya to be able to read it inside one project. Jordan opens the credential’s access panel, adds Priya, and picks:

Choice	What it means
Person	One named person. Not a group, not “everyone in the project”.
Operation	One specific thing, like reading mail. Read doesn’t imply send.
Project	Where it works. Priya’s turns in other projects are still denied.
Tool	Which tool may spend it.
Expiry (optional)	When the share ends on its own.

That’s the whole grant. It covers Priya’s own interactive turns — not her background jobs, not her scheduled tasks, and not anyone she talks to. Changing a share replaces the old one and cancels anything that was built on it.

To end it, remove the person from the panel. Access stops before the next request goes out. Requests already sent upstream may still come back with data — nothing can un-send those.

Approving a use

When an agent wants to use a credential that requires confirmation, the card goes to the person whose turn it is — and only to them. They have to already have access; being in the conversation isn’t enough, and nobody else can answer it on their behalf.

The card names the operation, the tool, the project, and who is asking. The usual answer is Allow this turn. Where the credential’s owner permits longer approvals, you may also see Allow this session, Allow 1 hour, Allow 8 hours, or Custom duration. There’s always a Don’t allow.

The owner chooses which longer options are available for each operation and may lower the remembered-approval limit from its 8-hour ceiling. Changing those choices ends approvals made under the old rules. The credential’s access panel shows the current choices and limit.

Anything longer than a turn shows up as a status line — “Mail read allowed for Priya in this session until 5:00 PM” — with a Stop allowing next to it. Some things worth knowing:

• The clock is fixed. Using the credential again doesn’t extend it, and neither does resuming the conversation or restarting the box.
• It ends at its time, at Stop allowing, when the session is deleted, or when the underlying share ends — whichever comes first.
• It’s yours alone. It doesn’t cover another person, another session, a branched conversation, or a background job.
• Nothing you approve in a conversation makes an unattended job work. Those are denied immediately rather than waiting for someone to answer.

If you’re the owner, you can go further and mark one operation ongoing for yourself or for someone you’ve shared with, so that person stops being asked for that exact operation, project, and tool. It’s an owner-only setting, deliberately narrow — it changes nothing else about the credential, and a grantee can’t grant it to themselves or widen it. Ongoing access still applies only while that person is present in an interactive turn; a background job needs a separately approved delegation. Remove the ongoing choice (or remove the person’s share) and the next matching use prompts again.

Scheduled jobs and credentials

A scheduled job never inherits the credential access of whoever wrote it. Jobs carried over from older versions of Lowkey keep the approval their owner gave, and that approval is pinned to an exact snapshot of the job: its script, notes, schedule, settings, declared dependencies, and the agent and prompts it runs with. A scheduled task created since then does not pick up anyone’s approval.

When you approve a job’s snapshot, two things to do first:

1. Read the warnings. The snapshot comes with an advisory review that flags patterns like downloading and running code, or reaching for programs outside the snapshot. It’s advice, not a verdict — a clean report is not a promise that the script is safe, and code the job builds or downloads while it runs isn’t covered by the snapshot at all.
2. Check where the results go. Approving credential use is not the same as controlling who reads the output. Look at which project the job writes into and who’s in it.

Edit an approved job afterwards — the script, its schedule, a dependency — and the approval goes stale: those runs stop until the owner approves the new snapshot. A run already going keeps using the snapshot it started with. You can withdraw the approval at any time from the access panel.

What this does and doesn’t protect

Worth being straight about, because the boundaries matter:

• Fetched data is out of scope. If an agent reads your mail and writes it into a shared project, everyone in that project can read it — the credential rules governed the fetch, not the copy. Revoking access later doesn’t pull it back. Private output needs a separate project with its own access list.
• This isn’t isolation between people’s processes. Agent turns run under one shared account on the box. Lowkey enforces who may ask for a credential; it does not claim one turn can’t interfere with another’s running process. Share a box with people you trust.
• Admins can’t help themselves to your credentials. Your admin can see a safe inventory and can revoke a credential in an emergency, and that’s audited. There’s no ownership transfer and no way to export the secret. The Lowkey team runs your box and has root on it, and root sits outside these rules — that’s the one party you’re trusting beyond your own admins.

The access panel shows two separate facts about your box, and they mean different things:

Badge	What it tells you
User authorization	Per-person credential rules are being enforced.
Worker/daemon boundary	Agent processes are fenced off from the vault itself.

You need the second one before you can say an agent cannot read the vault key. With it off you can still test the rules, but that’s all it is — a test. You won’t see a single “secure” badge here, because those two answers can differ.

What to read next

• Bringing people into a project → Working with other people
• The commands behind all of this → the lowkey-cli skill’s credentials reference