Non-Human Identity for AI Agents at the Gateway

TL;DR

• A non-human identity is a credential plus policy owned by software, and every production AI agent should have its own instead of sharing a provider key.
• An agent identity is only useful when it carries scoped model and tool access, a budget, rate limits, a named owner, and an audit trail.
• In Bifrost, a virtual key serves as the agent's identity: deny-by-default for providers and MCP tools, with its own budgets, rate limits, and log metadata.
• Bifrost Agent Gateway removes the caller's Bifrost credential by default; a trusted agent can forward it so its calls follow the caller's rules, or use its own key.
• Agent Logs record the caller of each agent operation, and two correlation headers link it to the model and tool calls behind it.

A non-human identity (NHI) is a credential, and the policy attached to it, that authenticates software instead of a person: a service account, an API key, a workload token, or an AI agent. Many AI agents still call models through a shared provider key with no owner, no spending limit, and no record of which agent did what. Bifrost, the open-source AI gateway built by Maxim AI, gives each agent its own identity at the gateway, with scoped access, budgets, rate limits, and logs, plus explicit rules for whose credential an agent uses on someone else's behalf.

What Is a Non-Human Identity?

A non-human identity is any identity that authenticates software rather than a person, such as service accounts, API keys, OAuth clients, workload tokens, and AI agents. It needs an owner, a scope, a lifecycle, and an activity record, but rarely has MFA, a manager, or an offboarding process.

The population is large. CyberArk's 2025 Identity Security Landscape report counts 82 machine identities for every human in organizations worldwide and finds that 42% of machine identities have privileged or sensitive access.

AI agents differ from older non-human identities in three ways:

• Runtime behavior. Model output, not a fixed code path, determines which tools an agent calls.
• Direct spend. Every model call costs money, so an agent identity needs a budget.
• Delegation. Agents hand work to other agents, so one task can involve several identities.

Agent identity sits inside the broader AI agent governance model of identity, permissions, budgets, and lifecycle; this post covers the identity layer and what changes when agents call other agents.

Why Every AI Agent Needs Its Own Agent Identity

A shared credential makes agents indistinguishable. When three agents call models with one provider key, a cost spike or an unexpected tool call cannot be traced to a specific agent or owner, and revoking access for one agent breaks all three. A per-agent identity makes each request attributable, limitable, and individually revocable.

Figure 1: A per-agent virtual key turns three indistinguishable callers into three identities with their own scope, budget, and log trail.

Shared keys fail in three places:

• Attribution. Provider dashboards show one key's usage, so nobody can say which agent generated the bill.
• Revocation. Rotating the key to stop one misbehaving agent takes down every other agent with it.
• Least privilege. A provider key reaches every model on the account, including the most expensive one.

The same reasoning applies to securing coding agent access with an AI gateway.

What an AI Agent Identity Must Carry

An AI agent identity is a credential bound to policy. A credential alone proves which agent sent a request; combined with scope, budget, rate limits, ownership, a lifecycle, and logging, it answers what an operator asks after an incident: which agent, owned by whom, allowed to do what, at what cost.

Each row is enforced at the gateway, not in the agent's own code. The Bifrost governance overview shows how these controls fit together across an organization.

Non-Human Identity Risks That Apply to AI Agents

The OWASP Non-Human Identities Top 10 catalogs the most common NHI failures, and most map directly onto AI agents. Several controls are cheapest to apply once at the gateway.

• NHI1 Improper Offboarding. Retired agents keep working keys. A virtual key can be deactivated instantly or given an expiry.
• NHI2 Secret Leakage and NHI7 Long-Lived Secrets. Agents holding provider keys spread those secrets. Behind a gateway, agents hold only a revocable virtual key.
• NHI5 Overprivileged NHI. Virtual keys deny providers and MCP tools by default.
• NHI9 NHI Reuse. Issue one virtual key per agent.
• NHI10 Human Use of NHI. Give people their own identities through SSO and keep agent keys for agents.

AI agent audit logs for tool usage surface the same patterns after the fact.

How Virtual Keys Give Agents Identities at the Gateway

In the Bifrost AI gateway, a virtual key is the primary governance entity, so issuing one virtual key per agent gives that agent a distinct identity. The key carries the agent's allowed providers, models, and MCP tools, its budgets and rate limits, an optional expiry, and owner metadata copied onto every log entry.

Figure 2: A request reaches a model or tool only after every check tied to the agent's key passes, and each refusal names the key.

As Figure 2 shows, each check is tied to the key the agent presents:

• Validity. An inactive or expired key is rejected with a 403 for inference and MCP tool execution; with enforce_auth_on_inference on, a request with no key gets a 401.
• Model and tool scope. Providers and MCP tool filtering are both deny-by-default, so the agent reaches only what its key lists.
• Spend and rate. Budgets and rate limits apply per key, with reset periods from one minute to one year, alongside any team or customer budget.

Creating a research agent's identity is one API call:

curl -X POST <http://localhost:8080/api/governance/virtual-keys> \
  -H "Content-Type: application/json" \
  -d '{
    "name": "research-agent",
    "metadata": { "owner": "platform@example.com" },
    "provider_configs": [
      { "provider": "openai", "allowed_models": ["gpt-4o-mini"], "key_ids": ["*"] }
    ],
    "mcp_configs": [
      { "mcp_client_name": "docs-search", "tools_to_execute": ["search"] }
    ],
    "budgets": [{ "max_limit": 50.00, "reset_duration": "1M" }],
    "rate_limit": { "request_max_limit": 60, "request_reset_duration": "1m" }
  }'

For key design across teams, see enterprise AI governance with virtual keys.

Agent Identity Across A2A Agent Calls

When an application calls an agent that then calls models and tools, two questions arise: who may call the agent, and whose identity the agent uses for its own calls. Agent Gateway in Bifrost, launched on October 20, 2026, answers both for agents that speak the A2A protocol.

Per-agent grants answer the first question. A virtual key can be given access to specific registered agents, or an agent can enable "Allow any virtual key"; authentication enforcement rejects anonymous calls. Permission to call an agent does not grant access to the models or MCP tools that agent uses.

Figure 3: Forwarding keeps the original caller accountable for the agent's work; an agent-owned key makes the agent accountable for its own spend.

The second question is the credential-handling model, shown in Figure 3:

• Default: strip. Bifrost removes the caller's Bifrost credential before forwarding the request to the agent.
• Forward Bifrost authentication. For a trusted agent, the caller's credential is passed along and reused on the agent's model and tool calls through Bifrost, which then follow the original caller's access rules and configured budgets.
• Agent-owned key. The agent calls Bifrost with its own virtual key, and that key's permissions and budgets apply.

Callers send their key in the x-bf-vk header, and agent access controls can be set in the dashboard or in config.json with allow_by_default and virtual_key_ids per agent.

Choosing a Credential Model for Each Agent

The right credential model depends on whose budget and permissions should govern the agent's work. Forward the caller's credential when a trusted agent acts strictly on a caller's behalf, use an agent-owned key when the spend belongs to the agent, and keep the default when the agent makes no Bifrost calls.

Figure 4: Forward the caller's credential only to agents you trust with it; every other agent either receives no Bifrost key or uses its own.

With forwarding, the agent server must keep each credential in that task's own state and send it only to Bifrost, or concurrent tasks can mix up callers. See the credential forwarding setup, and for SDK-built agents, routing the Claude Agent SDK through a gateway.

Human Identity, RBAC, and Non-Human Identity Management

Non-human identity management also covers the people who create and change agent identities. In Bifrost Enterprise, human identity comes from the corporate identity provider through SSO and SCIM, roles control who can manage keys, and access profiles apply one policy to many holders.

• SSO and provisioning. User provisioning connects Okta, Microsoft Entra, Google Workspace, and other OIDC providers, and removes users the identity provider deactivates.
• Roles. Role-based access control ships Admin, Developer, and Viewer roles plus custom roles, and maps them from identity-provider groups.
• Reusable policy. Access profiles define providers, models, budgets, rate limits, MCP tools, and agent access once, and lock a profile-governed key against direct edits.

The Bifrost Enterprise deployment adds these controls on top of the open-source gateway, and governing enterprise AI with virtual keys, budgets, and RBAC walks through a full rollout.

Building an Audit Trail for AI Agent Identities

An audit trail for AI agents needs three records: what each agent identity sent to models and tools, which caller started each agent task, and who changed the policies. Bifrost as an agent gateway keeps all three, so an incident review can move from a cost spike to the agent, the caller, and the configuration change behind it.

• Model and tool calls. Request logs capture inputs, outputs, tokens, cost, and latency, tagged with the virtual key's metadata.
• Agent operations. Agent Logs show the messages, task updates, and results of each conversation, with the recorded caller and the agent's latency alongside Bifrost's added overhead.
• Configuration changes. Audit logs in Bifrost Enterprise record administrative activity, can be signed with an HMAC key, and export as JSON, JSON Lines, or Syslog.

Two headers on the agent's Bifrost requests, x-bf-session-id (the A2A context ID) and x-bf-agent-correlation-id (the A2A task ID), connect an agent operation to its model and tool calls. The Agent Gateway launch shows this view in practice, and the hub guide to governing AI agents in production covers how logs feed the agent lifecycle.

Frequently Asked Questions

Are AI agents non-human identities?

Yes. An AI agent authenticates to models, tools, and other agents as software, not as a person, which makes it a non-human identity. It needs the controls of a service account (an owner, least-privilege scope, a lifecycle, and logging) plus a budget and rate limits, because every model call has a direct cost. Bifrost virtual keys carry all of these per agent.

What is the difference between a user identity and an agent identity?

A user identity represents a person who signs in, holds a role, and is deprovisioned when they leave. An agent identity represents a workload that runs continuously and may act for many users. In Bifrost Enterprise, people sign in through SSO with roles from the identity provider, while agents present their own virtual keys with scoped models, tools, budgets, and rate limits.

How do you give an AI agent its own identity?

Issue one credential per agent and attach policy to it at a gateway in front of models and tools. In Bifrost, create a virtual key for the agent, list its allowed providers, models, and MCP tools, set a budget and rate limit, add owner metadata, and make virtual keys mandatory so no request can bypass the identity check.

Should an AI agent use the caller's credentials or its own?

Use the caller's credential when a trusted agent acts on one caller's behalf and its usage should count against that caller. Use an agent-owned key when the spend belongs to the agent or the agent is not trusted with caller credentials. Bifrost Agent Gateway strips the caller's credential by default and forwards it only when "Forward Bifrost authentication" is enabled.

What is non-human identity management?

Non-human identity management is the practice of inventorying, scoping, rotating, monitoring, and retiring identities that belong to software. For AI agents, it means one identity per agent, deny-by-default access, budgets and rate limits per identity, deactivation when the agent is retired, and logs that attribute each request to an owner.

Start Giving AI Agents Their Own Identity with Bifrost

A non-human identity for each AI agent, enforced at the gateway, turns a shared provider key into scoped, budgeted, and auditable access, and the Agent Gateway credential model keeps that identity intact when agents call other agents. To see it on your own workloads, explore the Bifrost resources hub or book a demo with the Bifrost team.