| Decides each tool call inline | Every agent tool call is allowed or denied before it reaches the protected system. | Yes Vekri Gateway decides every MCP tool call sent through it before the broker executes it; a denied call never reaches the system. It is a boundary only when it is the only path to that system. | Documented Agent Gateway sits between agents and remote MCP servers and checks identity and policy for each tool call. Through other resource connections, such as Cross App Access, the agent receives a token and calls the resource directly. [1] [10] |
|---|
| Verified workload identity | An agent running as a workload proves who it is with a credential the platform issued, not a shared key. | Yes Kubernetes projected service-account tokens, verified with TokenReview before Vekri issues a short-lived token for the run; every call is then authenticated. SPIFFE X.509-SVIDs from a configured trust bundle (no Workload API yet). | Partly Each agent is registered as a workload principal and authenticates with a client secret, a key pair or a Client ID Metadata Document. Attestation from Kubernetes, a cloud platform or SPIFFE is not described. [1] [3] |
|---|
| Employee agents use company SSO | Agents that employees run sign in as that employee, through the company identity provider. | Yes Vekri is the MCP authorization server for Claude Code and federates to your OpenID Connect provider. SAML sign-in is not available yet. | Documented Employees sign in through Okta, and the agent obtains its gateway token for them with the authorization code flow and PKCE. [1] |
|---|
| Task-scoped permissions from the server | What an agent may do is set per task by the server, not by the agent or its prompt. | Yes A run scope for workloads, or a protected access assignment for employees. The effective permission is always an intersection, never a widening. | Not in public docs Access is set for each agent through resource connections and the tools selected for a gateway. A scope issued by the server for each task is not described. [2] [4] |
|---|
| Policy as code, deny by default | Decisions come from versioned policy, and anything not allowed is refused. | Yes Cedar over typed operations. Unknown operations and evaluation errors are denied, and a revision can be simulated before it is published. | Partly Administrators choose the agents allowed to call a gateway, up to 200 tools for it, and the scopes each resource connection allows. A policy language for these rules is not described. [2] [4] |
|---|
| Approval of the exact operation | A person approves one specific operation, and the approval cannot be reused for another. | Yes Privileged writes wait for another person to approve that operation, bound to its digest, short-lived and single use, with separation of duties. | Partly Auth0 asynchronous authorization lets an agent ask the user to approve an action on another device, optionally showing its details, before a token is issued. Approval of a tool call in Agent Gateway is not described. [5] [1] |
|---|
| Agent never holds backend credentials | Secrets for the protected system stay out of the agent's reach. | Yes A broker executes with narrowly scoped Kubernetes or GitHub App credentials. Incoming tokens are never forwarded. | Documented Agent Gateway obtains downstream tokens by token exchange and injects them, so the agent holds no credential for the remote service. Cross App Access and Auth0 Token Vault instead give the agent short-lived access tokens. [1] [10] [6] |
|---|
| Audit evidence of decision and outcome | Each call leaves a durable record of what was decided and what happened. | Yes Intent is recorded durably before execution and the outcome after; an uncertain outcome is never retried blindly. | Documented Gateway audit records attribute each tool call to the agent's workload principal, and each gateway shows 30 days of activity. The System Log records token exchanges and authentication events. [1] [7] |
|---|
| AI agents on workstations | Finds AI coding agents and other AI applications on employee devices, and watches or controls what they do there. | Partly Vekri Endpoint discovers coding agents, desktop and IDE AI apps, local models and their MCP servers on macOS and Linux, and its local MCP gateway decides each MCP tool call sent through it (Claude Code verified connecting; tool calls verified with an MCP client library). On macOS, a network gateway mediates MCP requests to approved remote servers, and agent control stops AI agents the organization has not allowed. Hooks observe built-in tools without blocking them; Windows is not supported. | Not in public docs Okta detects new agents from OAuth consent grants in managed Chrome browsers. Discovering or monitoring coding agents on workstations is not described. [8] |
|---|
| Prompt and output inspection | Detects prompt injection or sensitive data in what models read and write. | Partly Tool results on Vekri Gateway and the local MCP gateway are inspected for prompt injection before the agent reads them; sensitive-data categories are detected on the device, off by default. Browsers and file uploads are not inspected. | Not in public docs Inspecting prompts or tool output is not described in the public documentation. |
|---|
| Systems covered | Which systems, platforms or agents the product works with. | Kubernetes and GitHub, with GitLab, PostgreSQL, MySQL, MongoDB, Slack, Jira, Linear, Asana, ClickUp, monday.com, HubSpot, Pipedrive, Zendesk, Freshdesk and custom OpenAPI connectors in preview. | Agents built in house or imported from Salesforce Agentforce, Amazon Bedrock AgentCore and ServiceNow, reaching applications, authorization servers, vaulted secrets, service accounts and remote MCP servers. Auth0 Token Vault lists more than 30 integrations. |
|---|
| Deployment | How the product is delivered. | In Vekri's cloud, or self-hosted in your Kubernetes cluster with no connection to Vekri. | SaaS. Agent Gateway runs as an Okta-hosted relay and reaches remote MCP servers only. Auth0 for AI Agents is a separate developer platform from the same vendor. |
|---|