# GrubX: full site text for AI agents

GrubX is a runtime action firewall for AI agents. Canonical site: https://grubx.io/

## Summary
GrubX checks every agent action (an MCP tool call, an API request, a SaaS operation) against the customer's policy before it executes. It can allow the action, block it, or route it to a human for approval. Every decision is recorded as evidence. There is no SDK and no agent code change: the agent's MCP server URL or API base URL is pointed at a GrubX endpoint.

## The problem
AI agents now take real actions: they issue refunds, edit records, call internal APIs, and act for real users, often with only an API key and a prompt. Existing controls (IAM, API gateways, prompts and system instructions) were not built to judge individual agent actions. Security teams say no, and agents stay stuck in pilot.

## How it works
1. Sign up and get a tenant endpoint.
2. Change one URL (the MCP server URL or API base URL the agent already uses).
3. Run in Audit mode: GrubX records what it would allow, would block, and would send for approval. Nothing is blocked in Audit mode.
4. Review the Top Risks dashboard.
5. Activate Protection to enforce policy (Active mode). A kill switch stops one agent or all agents in any mode.

## Capabilities
- Allow, block, or require approval: three decisions on every action. Approvals are asynchronous and bound to the exact action.
- Parameter-aware policy: rules on amounts, targets, and scopes, written as code (Cedar), versioned and testable.
- Limits and agent budgets: per-transaction and cumulative caps per agent, session, or day.
- Secret and PII detection in outbound calls, redacted before anything is stored.
- Session-aware rules: an agent that read customer PII cannot email it externally.
- Kill switch.
- Credential brokering: agents never hold upstream keys; GrubX injects them at runtime.
- Evidence: tamper-evident, hash-chained decision records; exportable evidence pack.

## Security design
- Secrets are never stored in the database, logs, or audit trail; brokered credentials stay in the customer's secrets manager.
- Fail-closed for writes, payments, and destructive actions; fail-open only for read-only actions if the customer allows it. Every fallback is audited.
- Policy is evaluated in-process in the gateway; gateways keep enforcing the last known policy if the control plane is unreachable.
- Tenant isolation: records, policy bundles, and audit chains are scoped per customer.
- Parameters are redacted or hashed per field; raw PII is not retained.
- Hosted on AWS today; a customer-hosted gateway for a customer's own VPC is on the roadmap.
- Latency target: under 2 ms p99 for the decision, under 10 ms end to end (targets, not guarantees).

## Pricing
- Free: $0. Up to 3 agents, 50,000 actions per month, Audit and Active modes, starter policies and kill switch, 7-day decision history.
- Enterprise: contact hello@grubx.io. Unlimited agents, volume-based pricing, approvals, spend limits and agent budgets, credential brokering and custom policies, evidence export and long-term retention, SSO, private deployment options, dedicated support.

## FAQ
Q: Do we have to change our agent code? A: No. There is no SDK. Change the MCP server URL or API base URL your agent already uses. Works with any agent framework.
Q: How is GrubX different from NVIDIA OpenShell? A: Different layers that fit together. OpenShell sandboxes the agent (files, processes, network destinations, MCP tools, credentials). GrubX reads the arguments of each tool call or API request and decides whether that specific action should run, needs approval, or is blocked, with a tamper-evident record. GrubX works inside an OpenShell sandbox.
Q: How much latency does it add? A: Policy is evaluated in-process; target under 2 ms p99 for the decision and under 10 ms end to end.
Q: What if GrubX is unavailable? A: Gateways keep enforcing the last known policy. Failure mode is chosen per action: fail-closed for payments, writes, deletes.
Q: Do you see or store our secrets and data? A: Secrets are never stored or logged. Parameters are redacted or hashed field by field; raw PII is not retained.
Q: Can an agent bypass GrubX? A: Only if it holds its own keys. With credential brokering, agents authenticate to GrubX and never see upstream credentials.
Q: What about internal APIs? A: MCP tools and common SaaS APIs are recognized out of the box. For internal services, upload an OpenAPI spec and GrubX maps each operation to a named action with typed parameters.

## Terms this product answers to
AI agent security, agentic governance, AI agent governance, agent runtime security, agent authorization, MCP security, MCP gateway policy, guardrails for AI agents that act, human-in-the-loop approval for agents, audit trail for AI agents, agent kill switch, least privilege for AI agents.

## Contact
hello@grubx.io