dhvati verifies who's acting, decides every tool call against policy, injects credentials from its vault when a call is allowed, and audits everything. This guide covers the whole loop: connecting your agent, integrating your apps, shaping policy, and reading the trail.
Three pieces, one loop:
https://mcp.dhvati.ai/mcp, an MCP server your agent talks to. It's the same URL for everyone; who you are is decided at sign-in, never by the link.Every agent connects the same way: point it at your endpoint, sign in once in the browser that opens. No API keys, nothing pasted into the agent.
https://mcp.dhvati.ai/mcp
Step-by-step instructions with copy-paste blocks for each harness live on Connect your agent — about two minutes each.
The browser window is dhvati verifying you — not the agent. Register creates a free personal workspace on the spot; if your company runs dhvati, use your company's button on the same screen and your org's roles and policies apply automatically. Either way, from the next call onward every request carries your verified identity.
Apps ("tools") are what your agent acts on — Slack, GitHub, internal APIs, any MCP server. You integrate them once in the Console; the credential lands in the vault and is injected per allowed call. The agent never sees it.
slack.read_channel, slack.post_message, …) now show up on the Roles & Policies page, ready to allow, deny, or leave as ask-first.If a tool speaks MCP — a vendor's hosted server or something your team built — dhvati can govern it. Add it from Integrations → Add MCP server with its URL, then pick how dhvati should authenticate to it:
For apps in per-user OAuth mode, each teammate authorizes once at the connection hub:
https://mcp.dhvati.ai/connect
It lists every app that needs a personal connection, shows what's already linked CONNECTED, and walks through the vendor's own consent screen for the rest. If an agent calls a tool the person hasn't connected yet, the deny message links straight here.
Fresh workspaces come with a demo tool pre-integrated so you can watch governance work before wiring up anything real: reads like demo.lookup_order are allowed, writes are ask-first — deny → request → approve → allow, all visible in your audit trail within minutes of signing up.
The Roles & Policies page is a matrix: roles down the side, tool actions across the top, and an allow/deny state in each cell. Anything unstated is denied by default. The matrix compiles to Cedar and the Gateway enforces the new policy within seconds of saving — you can simulate "would this person be allowed?" before you commit.
Personal workspaces start with the pattern we recommend everywhere: reads flow, writes ask. When an agent hits an ask-first action, the call is held, the person (or an owner/admin) sees it on the Console dashboard with the agent's stated reason, and one tap resolves it — approve once, grant for a window, or deny. The agent continues (or stops) live.
Approvals can create a GRANT — permission for a specific person and action that expires on its own (hours or days). No standing access accumulates: when the grant lapses, the action goes back to ask-first. Active grants are listed on the dashboard and revocable at any time.
Settings → Members → Invite creates a one-time link. Teammates who join get the Member role — reads allowed, writes ask you — and every one of their agents' calls lands in the same audit trail. Roles are editable per person.
Organizations connect their own IdP so employees sign in with company credentials and policy binds to real directory roles — no separate accounts to manage. Keycloak-backed OIDC is live today; SAML/SCIM and further IdPs are rolling out with design partners — talk to us. Enterprises can also run the entire stack on their own infrastructure: see Security & deployment.
Every decision the Gateway makes is recorded: timestamp, the acting person, the tool and action, ALLOW or DENY, and why — including which rule or grant decided it. A deny links to the request it created; a grant links back to who approved it. The trail lives in the Console's Audit page. dhvati records that calls happened and what was decided — it does not retain your tools' response payloads (see the privacy policy).
SIEM streaming is on the near-term roadmap; export works today.
Make sure you completed the sign-in the browser opened. In Claude Desktop, check the connector is enabled under Search & tools; in Claude Code, run /mcp and confirm dhvati shows as connected.
No — that's the product working. The deny message names the policy reason. If it's an ask-first action, the request is already waiting on the Console dashboard for one-tap approval. If you are the workspace owner, you approve your own requests there.
For per-user OAuth apps, visit mcp.dhvati.ai/connect and (re)connect your account — tokens are refreshed automatically, but a revoked upstream grant needs one fresh consent.
Sign out at my.dhvati.ai, then retry the connector — it will reopen the sign-in. Still stuck? vishwa@dhvati.com — a human reads it.