Questions about how Clawvisor works.

No. Real secrets stay in the vault, and the agent is not given a stand-in for them either. It sends the service and action it wants, and Clawvisor attaches the real credential inside the gateway. The credential is never placed in the agent's context, the model prompt, or the response.

Both, deliberately. The vault is where the secret lives at rest, encrypted and out of reach of the agent. The gateway is the enforcement point: every call routes through it, which injects the credential only after the call passes purpose and policy checks. Vaulting without an enforcement point still lets a compromised agent ask for the secret. Forwarding without a vault still leaves the secret reachable. You need both.

A pure pass-through gateway has to get its upstream credential from somewhere, and if that lives next to the agent it is one prompt injection away from exposure. Holding the secret in the vault means the credential exists in exactly one controlled place, and the agent works entirely through handles it cannot exchange for the underlying secret.

The handle the agent was using is revoked with the task. There is nothing for the agent to keep, cache, or replay later, because it never held the credential and the handle no longer resolves.

On the managed cloud they are stored encrypted and injected at call time; they are never exposed to agents or model context. On self-hosted, the vault runs inside your own network and we never see your traffic at all.

A task is the authorized unit of work. It carries the declared purpose, the policy decision that approved it, the set of tool calls it is allowed to make, and the human it is tied back to. Every protected tool call belongs to exactly one task.

A task ends when its work is done, when it hits its time or call budget, or when someone revokes it. Agents start with zero standing access, so expiry is the normal state. Access exists only while a task is open, and the moment it closes the granted tools are withdrawn.

It fails closed. The handles issued for that task stop resolving, so any further call the agent attempts is denied. A task that is over cannot reach what it could reach a moment earlier, even if the agent still tries.

No. Standing access is the thing Clawvisor exists to remove. A long-running agent opens a fresh task each time it needs to act, and each task is scoped and bounded on its own, so there is no permanent grant for a compromised loop to ride on.

At most what that one task was approved to do. Because tools are granted per task and revoked when it ends, a hijacked prompt cannot reach anything the task never needed, and it cannot extend its own lifetime to keep going.

Yes. The gateway source is public and self-hostable. You run it inside your own network, you operate it, and we never see your traffic. It is the same gateway that powers the managed cloud.

Somewhere to run the gateway service inside your network, a datastore for the vault and audit log, outbound reach to the tools and APIs your agents call, and an API key for an LLM provider — that key is what powers purpose verification and risk scoring, and setup turns both on once you supply it. The install script drops the daemon in for you, or you build from source, which needs Go 1.25+ and Node.js 18+; the GitHub repo is the canonical setup guide and walks through configuration and connecting your accounts. Point your agent at it with the skill and calls start flowing through it.

Yours. You point it at Anthropic, OpenAI, Google Vertex AI, Groq, or a local Ollama model, and a small fast model is plenty — the verifier only sees request metadata, not your data. Chain-context extraction is the one check that is off unless you opt in, because it sends API responses to the model to follow references between calls.

You add a skill that teaches your agent to fetch data through Clawvisor instead of calling services directly, pointed at the gateway on port 25297. There is no SDK and no change to your agent's code. From then on the agent declares a purpose with each request, and the gateway verifies it, injects the real credential from the vault, and logs the call. Your API keys never reach the agent.

Less than you might expect. The gateway is the same, and so are purpose verification, risk scoring, the credential vault, and the audit trail — self-hosting gets all of them. What the managed cloud adds is longer log retention, org and team accounts, and removing the operational burden of running, updating, and backing up the service. Self-hosting trades that convenience for full control and isolation.

No. On self-hosted everything stays in your vault, in your network. We have no visibility into your secrets or your tool calls.

Yes. The core gateway, credential vaulting, per-task containment, and full audit trail are working and in use in front of real agents today. The source is public, so you deploy it today and control your own upgrade cadence.

Every protected tool call records the action, its arguments, the policy decision, and the task that authorized it, replayable and tied back to the human who approved the work. It is a full audit trail of what your agents did and why each call was allowed.

SAML and OIDC single sign-on already ship for Enterprise orgs. The near-term focus is hardening the enforcement path, expanding the evaluation suites, and adding the custom retention and data-residency options that Enterprise teams need. Self-hosting already gives security-sensitive teams full isolation today.

The source is public, so the fastest way to see what is shipping, raise an issue, or read the code is the repository. The community channel is where issues get answered and releases get discussed.