Integration hub
Integrations
Declare what agents can touch. Every integration decomposes into governable actions— allowed to no one until you grant them in Roles & Policies.
Every credential lives in dhvati's vault — injected by the Gateway at call time, never visible to agents.
2 integrations · 11 governable actions
GitHubnativeConfigured9 governable actions·5 roles with access
GitHubnativeConfigured
9 governable actions·5 roles with access
Your OAuth app · client Ov23liE1gb6goMx3SC68
github_list_repos· resource5 rolesgithub_create_issue· resource5 rolesgithub_read_issues· resourcedefault-denygithub_list_issues· resourcedefault-denygithub_add_comment· resourcedefault-denygithub_create_pr· resourcedefault-denygithub_list_pulls· resourcedefault-denygithub_merge_pr· resourcedefault-denygithub_get_file· resourcedefault-denySlacknativeConfigured2 governable actions·5 roles with access
SlacknativeConfigured
2 governable actions·5 roles with access
Your OAuth app · client 11673563163782.11672425241205
slack_read_messages· resource5 rolesslack_post_message· resource1 roleNo mcp servers yet.
No custom integrations yet.
New actions always arrive default-deny. Grant them per role in Roles & Policies.
Model providers
AI gatewayThe model your agents run on — dhvati holds the key and injects it at call time.
Anthropic
key •••••••• · in vault
Models
3claude-opus-4-8 · claude-sonnet-5 · claude-haiku-4-5
Agent must be scoped for
llm_completeHow this works
Agents never hold the model key. They call
<gateway>/llm with their own dhvati token; the Gateway verifies the caller, checks that its scope includes llm_complete, injects your provider key from the vault, forwards the call and audits it. The key is sealed at rest and never reaches the agent, its logs, or your developers — so a hosted agent can run with zero secrets of its own. Scope an agent for llm_complete on the Agents page to let it use the model.Custom & requested tools
Bring your own API under governance
Describe the internal API your agent needs. An admin adds the credential, dhvati takes custody of it and enforces every call — you never handle the secret.
1You describe the API→2An admin adds the credential→3Live · governed · assignable
How onboarding a custom tool works
A developer describes the API — host, auth type and the exact actions the agent needs — and submits it. The request lands here as Requested, and every call to that tool is denied fail-closed while it sits there: nothing runs ungoverned. An admin reviews it and pastes the credential, which goes straight into the org vault (sealed at rest) — the developer who asked for the tool never sees it. On save the tool goes Live: its actions become governable in Roles & Policies and assignable to an agent's scope, with dhvati injecting the credential on each call and auditing the result.