Questions & answers
The short version of how the permission model, credential isolation, audit log, and kill switch work — plus privacy, licensing, and how to run it yourself. Want the full detail? The source and docs are open.
A personal agent control harness: you run AI agents and govern them with grants, a tamper-evident audit log, spending caps, confirmations, and a real kill switch. The product page covers the guarantees; the questions below cover how it works and how it differs from the alternatives.
The runtime an agent's actions pass through before they touch your accounts. The model only proposes; the harness checks each proposal against your grants, runs it with credentials the model never sees, writes it to an audit record, and can stop everything at once. It ships assembled, so the safety properties hold without you wiring them together.
Anyone who wants agents working on their behalf without handing over the keys. It is a consumer product, not a developer SDK. The earliest adopters are technical people who already feel the governance pain and want controls they can actually trust.
Agents can now send, spend, delete, and post on your behalf, and what shipped alongside that power is mostly a confirmation dialog — rendered by the same software that runs the model, asking "allow?" until yes means nothing. Habenula moves the part that decides what an agent may do outside the model, into deterministic code the model cannot argue its way around.
Assistants and autonomous agents are about capability: getting more done for you. Habenula is about authority: deciding what a capable agent is allowed to do, and proving what it did. It runs agents too, but the product is the governance around them.
That prompt is the model choosing to pause and ask, in its own words. A mistaken or manipulated model can word it to look harmless, ask for the wrong thing, or not ask at all.
Habenula's check isn't the model's to make. Code on the only path to execution turns every consequential action into (service, verb, noun), so you see the actual call — the real recipient and scope — and an action the model never mentioned is still held. The same runtime also keeps credentials away from the model, logs what ran, and gives you a kill switch.
No. A gateway filters tool calls in front of a runtime someone else owns, so it cannot keep credentials away from the model or contain what tools return. A toolkit ships the parts and leaves the security-critical assembly to each developer. Habenula owns the whole runtime and ships it assembled, so the guarantees hold end to end.
Habenula, not the model, runs a fixed sequence for every tool call: turn the request into a precise action, check it against your grants and spending caps, write the decision to the audit log, and only then run it with credentials the model never sees. Anything you have not granted is held for you instead of run.
The check is deterministic: the same grants and the same action always produce the same decision, with no model in the decision path. That makes it testable, rather than a matter of asking a model to police itself.
Habenula-authored, reviewed integrations. Available at launch: Gmail, Google Calendar, Slack, Outlook Mail, and GitHub. Two sandboxes let you try an agent before connecting anything real: a sandbox inbox, and a sandbox storefront where an over-budget order gets held for your approval, with no real money involved. Google Drive, Telegram, and WhatsApp are on the roadmap.
Tell us at hello@habenula.ai — requests steer what gets built next. Or, because the runtime is open source, write the integration yourself against the same tool registry the built-ins use.
What Habenula deliberately does not do is connect an arbitrary MCP server and give it the same guarantees. Precise, per-resource grants depend on a trusted mapping from a tool's raw calls to actions; an outside server would be declaring its own mapping, which is a tool setting its own permissions. Connecting outside servers is planned, with stricter defaults for anything unrecognized and a way to vet who published it. Until then, an unrecognized tool is held on every call.
A grant says who may do what, to which resource: (agent, service, verb, noun). Every verb is bound to a resource, so there is no bare "read: allow", and a wildcard never matches.
You build grants as you go. When an agent needs something it has not been granted, the call is held and you choose Allow once (this call only), Allow for 30 minutes (or a duration you pick, from 5 minutes to 30 days), Deny, or Tell me more (what the tool is and touches, no decision). There is no "always allow": every grant is one-time or timed, and expires on its own.
No. There is no upfront setup: the agent asks when it needs something, and your answer is the grant. A timed grant covers every matching action while it lasts, so the same request does not ask twice; a different recipient is a different grant. Routine and already-granted actions just run, and because every grant expires, there is no standing list to manage. Approving a whole multi-step task as one plan is the planned next step.
Not yet. Today a grant binds an exact resource — this set of recipients, this channel — so "work email only" builds up grant by grant as the agent asks. Scoping an intent up front to a pattern (domains, labels, paths) is designed but not built. When it lands, you will still set the pattern before the run; the gate will never leave "is this one work-related?" for the model to judge.
One command, habenula kill, deletes every grant and clears every held call in a single step, so everything is denied until you grant it again. It acts on grants only: your connected services and stored credentials survive, so you resume without signing in again. A still-valid credential authorizes nothing while nothing is granted. Revoking tokens at the provider as an extra layer is planned.
Yes. Paid actions are priced before they run and checked against a per-session cap and a per-month cap, both on by default and both adjustable. Going over turns into a confirmation naming the exact amount. Today the only paid action is the sandbox storefront, so no real money moves yet. Per-service and per-transaction caps, and rate and time limits, are planned.
Every decision is written to an append-only log before the action runs, so even a failure is on the record. Each entry carries the hash of the one before it, so changing any entry visibly breaks the chain. By default the log records what kind of action went to which resource, not the content of your messages.
Check it yourself with habenula log verify, which recomputes every hash on your own machine; the format is published with test vectors so an independent tool can check it too. Automatic retention and archival are not built yet.
A session runs on a single clock — 90 minutes at launch — and ends when the clock runs out, taking any held calls with it. Grants follow their own terms: a one-time grant is used up by its call, and a timed grant expires at the time you chose. Sessions that ask to renew and stop unless you answer are planned, along with longer, configurable clocks for background agents.
Yes, as an opt-in: on macOS, a Touch ID check must succeed before a grant made in the command line takes effect, so an approval shows a person was present. It is a presence check today, not a signature bound to the exact action; hardware-backed signatures are planned.
It makes them governable, and keeps you the one governing. They are your agents acting on your behalf, so what they do is your responsibility; Habenula makes that responsibility workable. It holds new actions for approval, keeps grants narrow, records every call, and stops everything at once. The grants you give set how far a mistake can reach, and the defaults push them narrow.
It has honest edges. It does not read the content of a message on a channel you have allowed and judge it for you — partly for privacy, partly because what you send is your call. It checks the request, not the effect a tool has on a service Habenula does not run. And it judges each action on its own, not yet whole combinations across a task.
For the launch set — Gmail, Google Calendar, Slack, Outlook Mail, GitHub, each a Habenula-authored integration — this is largely theoretical. In general, a tool runs on infrastructure Habenula does not control, so it could report back something false; Habenula governs the call, not the tool's honesty. What a tool cannot do is trigger further actions you did not grant: those still face the gate, and every call is on the record.
Content an agent reads — an email, a web page — can try to steer the model. The defense is structural: whatever the model then asks to do still faces the deterministic gate and your narrow grants, so an injection can waste a turn but cannot spend, send, or delete beyond what you allowed. Untrusted content is also labeled as data, not instructions, when it reaches the model — a mitigation, not the guarantee.
No. An outside agent, such as a coding assistant, can commission a goal: it hands Habenula a request in its own words through a narrow interface, and can check how the run ended. That is all it can do. Your Habenula agent carries the work out under your grants, and every approval happens on your screen, never the commissioner's. It cannot see your integrations, call them, or use controls like kill; it gets back status, not the content behind your credentials.
At launch the local interface is unauthenticated and reachable only from your own machine, so the machine itself is the boundary: a malicious program already running as you is inside it. Account authentication that closes that gap is scheduled. We say this up front because a control product that overstates its boundary is exactly what this one exists to replace.
No. Sign-in tokens are stored encrypted and decrypted only for the instant a tool call runs, then discarded. They are never placed in the model's context or returned to it, so even a fully manipulated model has nothing to leak.
Not by Habenula. The launch version runs on your own machine, so there is no company-side inspection or logging. The runtime works on metadata — what kind of action, to which resource — and passes content through only to carry out an action you allowed. Your data travels only to the services you connect and the model you choose.
On your own machine, in an isolated per-user store: your credentials, grants, audit log, and history. Because you host it, Habenula, Inc. cannot reach any of it. Credentials are encrypted at rest; the rest is ordinary data on your disk, protected like your other files.
No. The shipped code has no telemetry, usage or crash reporting, or update check. Every network call goes to a service you connected or the model you chose, never back to Habenula.
That is covered by our privacy policy: what we collect when you visit habenula.ai, email us, or join the mailing list, and the choices you have. This section is about the product you run yourself.
Your choice, set per deployment: Anthropic's models, any provider that speaks the common OpenAI inference API, or local open-weight models. The gate judges the action, not the model, so your controls do not depend on the vendor you pick.
It is your call. Point Habenula at a hosted model and that provider processes what you send it; Habenula adds no step of its own to that path. Point it at a local open-weight model and nothing leaves your machine.
Yes, at launch: you supply the key for the provider you chose, or run a local model and need none. A managed option with model access included is planned for the hosted service.
Yes, under AGPL v3: the runtime, command line, integrations, governance pipeline, credential vault, and audit log. The trust-critical code stays open and free, permanently. The audit-log verifier alone is MIT, so an independent party can embed it and check the log without running Habenula.
Yes. If you have Node, npx habenula up starts the engine on your own machine in one step; then npx habenula starts a conversation once you add your model key (or point it at a local model). You can also run it as a container on any Docker host, or build from source. None of it needs a Cloudflare account or Habenula, Inc. Copy the commands from the product page.
Self-hosting on your own Cloudflare account follows on the same code, then a hosted service run by Habenula.
Not yet, and there is no date. When it comes, it will run the same open engine you can run yourself — not a lesser sibling of a closed product.
You can fork and modify freely under AGPL. Contributions back go through a contributor agreement, and the public repository mirrors the source rather than merging outside changes directly, so a pull request is a proposal the team can adopt.
Habenula, Inc. The name is borrowed from a brain region that acts as a hub for value-based decision-making — a neural brake.
AGPL v3, with the audit-log verifier under MIT. The code license grants no trademark rights; Habenula's names and logos are covered by the trademark policy in the repository.
Email security@habenula.ai, privately, before anything public. The security whitepaper lists the current limitations, and reports of anything it gets wrong are welcome.
Beny's Blog has the arguments and a survey of the field; the whitepapers have the depth on governance, security, and architecture.
We read everything. Reach out and we'll get back to you.
Contact us