| 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 Noma evaluates an action or connection when it is attempted and can block it in real time, enforcing through the AI and MCP gateways, agent hooks, agent SDKs and direct APIs the customer already runs. [2] [3] [4] |
|---|
| 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). | Not in public docs Noma ties agents to their human owners. Verifying an agent workload with a platform-issued credential on each request is not described in the public documentation. [5] |
|---|
| 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. | Partly Noma maps each agent to its human owner and that owner's IdP group, and keys policy to those groups. How an agent signs in as the employee is not described. [5] |
|---|
| 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 Noma compares attempted actions with the agent's intended task to detect drift. A permission scope issued by the server for each task is not described in the public documentation. [3] |
|---|
| 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 Policy is set per agent, tool and operation, keyed to IdP groups, users and tool sensitivity, and defined once for every control point. The policy language and deny-by-default behavior are not described. [3] [6] |
|---|
| 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 Policy can route an action to a person for approval. Who approves, and whether the approval is bound to that exact request, is not described. [3] [4] |
|---|
| 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. | Not in public docs Brokering or injecting backend credentials so that the agent never holds them is not described in the public documentation. |
|---|
| 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 Noma keeps a trail of agent actions, including prompts, tool calls and responses, with explanations of incidents and evidence for auditors. [3] [4] [6] |
|---|
| 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. | Documented Noma finds Claude Code, Claude Cowork, Codex, MCP servers and skills on employee devices through existing EDR or MDM tools, and stops risky actions through hooks, gateways and APIs. Which control point applies to each agent, and supported operating systems, are not stated. [2] |
|---|
| 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. | Documented AI-DR detects prompt injection, including encoded injection and indirect injection through tool responses, and can mask sensitive data inline. [4] |
|---|
| 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 on Microsoft Copilot Studio, Salesforce Agentforce and Claude Enterprise; agents built on Amazon Bedrock, Bedrock AgentCore and SageMaker; and Claude Code, Claude Cowork and Codex on employee devices. |
|---|
| Deployment | How the product is delivered. | In Vekri's cloud, or self-hosted in your Kubernetes cluster with no connection to Vekri. | Noma states that it supports both SaaS and on-premises deployment. It discovers SaaS agents through platform APIs and endpoint agents through existing EDR or MDM tools, and enforces policy through existing gateways, agent hooks, SDKs and APIs. |
|---|