Resources
Cap AI agent spend without blocking the teams that need agents
You cannot cap what you cannot identify. Put a gateway in your network that attributes spend by agent/team, blocks unsafe tools, and exports CRA-ready logs — then set caps.
Seat licenses count humans. Agents are workloads: they retry, loop, and share keys. UnitOne Gateway sits in your AWS VPC, Azure VNet, or GCP project so you can identify the agent, block unsafe tools, export CRA-style logs, and then set caps that do not freeze the teams that actually need agents. Security first, CRA evidence second, cost third. Start free on Gateway.
Identify the agent. Then set the cap.
- 1
Why seat metering fails for agents
A seat is a person who can open the console. An agent is an AI workload that calls models and tools. Two console seats can still run ten agents — or one unnamed script on a shared key. Seat metering assumes one human equals one usage stream. Agents do not: they fan out, retry, and call tools in loops. A seat limit does not stop a runaway tool loop, and it cannot tell a discovery experiment from a production agent serving customers. If spend rolls up to a team license, you cannot cap the unsafe workload without blocking the people who still need agents.
- 2
Identity → attribution → caps (Security → CRA evidence → Cost)
Give each agent, and the team or project that owns it, an identity on the gateway path. Security first: a named identity is what a deny policy attaches to. If a poisoned or over-scoped tool is invoked, Gateway can block that agent or that tool; a shared key has no one to deny. CRA evidence next: the same identity appears in exportable logs — which agent, which tool, allow or deny, timestamp. That is operational evidence for vulnerability handling and Article 14-style duties, not a legal determination of CRA scope. Cost last: attribute tokens, tool calls, and gateway events to the agent and team, then set a cap on the experiment without starving the published production agent. Free includes basic attribution and basic spend caps. Team adds full caps. Enterprise adds org policies.
- 3
What to log for vulnerability/incident evidence
This is a practical AppSec list, not legal advice. For a vulnerability or incident involving an agent, export: when it happened (timestamp); which agent, team, and project identities were on the request; which tool or MCP server was invoked; the policy decision (allow, deny, or unknown — unknown means the path was off-gateway); a correlation or request id so you can join model calls and tool calls; and what you blocked, if anything. An SBOM and a cost dashboard do not replace this log. If you cannot show the deny, you cannot show handling. Free retains 7 days, Team 30 days, Enterprise custom — export if your hold is longer.
- 4
Start free path (VPC Gateway)
Start free on Gateway. Free is $0 and includes Gateway in your AWS VPC, Azure VNet, or GCP project, 10 agents (AI workloads, not seats), 2 console seats, and 25,000 gateway events per month. After checkout you get deploy and login steps so the data plane stays in your network. Register discovery and production agents as separate identities. Confirm a tool can be denied and a log can be exported. Then set a basic cap. See plans for Team at $99/month. Talk to us for Enterprise SSO, retention, and org policies.
Frequently asked questions
- Why does seat metering fail for AI agents?
- Seats count humans in the console. Agents are AI workloads that call models and tools. Two seats can still run unnamed scripts, retries, and tool loops on a shared key. A seat limit does not identify which agent spent, so it cannot cap a runaway workload without also freezing the people who still need agents.
- How do identity, attribution, and spend caps work together?
- Identity names the agent and the team or project that owns it. Attribution attaches tokens, tool calls, and gateway events to that identity. Caps are limits on that named spend. The order is Security (deny on that identity) → CRA evidence (export that identity) → Cost (cap that identity). A cap without identity is a report, not control.
- How do you cap agent spend without blocking teams that need agents?
- Give discovery, experiment, and published production agents separate identities and budgets. Cap unpublished work tightly. Give production agents their own identity and a production cap. If they share a key, a cap on the prototype also stops the team that ships — or the production identity absorbs experiment spend and never trips.
- What should we log for vulnerability or incident evidence?
- Log time, agent/team/project identity, tool or MCP server, allow/deny/unknown, and a correlation id. Unknown means the call never hit the gateway. Export those logs for vulnerability handling. This is operational evidence, not legal advice, and it does not decide whether you are in CRA scope.
- How do I start free with Gateway in our VPC?
- Use Start free. Free is $0 and includes Gateway in your AWS VPC, Azure VNet, or GCP project, 10 agents (workloads, not seats), 2 console seats, and 25,000 gateway events per month. After checkout you get deploy and login steps. Finding → Fix Spec → PR remediation is a separate scoped POC.
Identify the agent. Then set the cap.
Start free on Gateway in your network. Attribute spend by agent and team, block unsafe tools, and export CRA-ready logs — then set caps that do not block the teams that need agents.
Need Finding → Fix Spec → PR work? Request a remediation POC — scoped, not the Gateway trial.