RunGuard

Google Cloud infrastructure + Datadog observability + Cloudflare security + premium AI startup landing page.
RunGuard Autonomous control layer

Inspiration

Autonomous agents can now reason, call tools, execute code, and spend real money without a human watching every step.

That creates a new failure mode: the agent can keep running long after something has gone wrong. A looping agent can burn through hundreds of thousands of tokens, while an unsafe tool call can touch credentials, secrets, or destructive commands before anyone notices.

RunGuard started from a simple question:

If we are comfortable letting agents operate autonomously, what is the seatbelt that keeps them inside a safe operating envelope?

RunGuard is a cost and safety governor for teams running Gemini Managed Agents. It sits between the agent and the provider, prices every run, enforces budgets before work starts, blocks unsafe sandbox actions, and records why every decision was made.

What it does

RunGuard acts as a control plane around autonomous Gemini agents.

When an agent starts an interaction, RunGuard automatically reads the project's state and remaining budget, calculates the maximum safe token allowance, evaluates tool calls against policy, and decides whether execution should continue or be stopped.

The token ceiling is clamped to the smallest of four limits: what the caller requested, the remaining project budget, the customer's plan limit, and RunGuard's global safety ceiling. After execution, RunGuard prices the interaction, records usage, and raises alerts when thresholds are crossed.

There is no human approval step in that loop.

The same applies to sandbox actions. Commands resembling recursive deletion, attempts to read .env files, or access to SSH credentials can be denied before execution.

Most importantly, every decision is explainable: RunGuard records the observed value, threshold, rule, and detector version instead of returning an opaque model judgement.

How we built it

RunGuard is built directly around Gemini's Interactions API and environment-hook interface.

The proxy modifies agent_config.max_total_tokens before forwarding an interaction upstream, consumes streamed usage events to calculate cost, understands Gemini's budget_exceeded termination state, and implements the environment-hook contract used to evaluate tool execution.

One important architectural decision was not to put an LLM inside the enforcement path.

Budget calculations, authorization, billing, policy evaluation, and allow/deny decisions are deterministic. If RunGuard blocks an action, the customer should be able to reproduce exactly why it happened. A safety decision that changes because a model was sampled twice is not a control.

Gemini is still load-bearing. It is the autonomous system RunGuard governs, and Gemini is also used in one deliberately isolated place: converting deterministic alert data into human-readable explanations. The model receives only whitelisted figures already computed by the engines, and the underlying alert is delivered independently of the model response.

Challenges we ran into

The hardest challenge was deciding where AI should stop.

It is tempting to ask a model whether a tool call "looks dangerous." That would be flexible, but it would also make enforcement probabilistic. For controls involving money, access, and destructive operations, we chose deterministic rules instead.

Another challenge was understanding the difference between a safety layer and a guarantee.

Gemini environment hooks are useful for defence in depth, but the provider treats hook failures or timeouts as approval. In other words, hooks can fail open. RunGuard therefore treats the proxy boundary — where a project can be paused before the request reaches the provider — as the stronger control.

We also had to be precise about evidence. The current captured evidence demonstrates autonomous decision-making against recorded fixtures; it does not by itself prove continuous production uptime or live Gemini billing. We chose to expose that limitation rather than hide it.

Accomplishments that we're proud of

The strongest accomplishment is that RunGuard already has measurable failure cases rather than only a dashboard demo.

In the captured evidence:

A runaway interaction that would consume 1,250,000 tokens was stopped at 312,498 tokens.
Recursive deletion was denied in roughly 35 ms.
Attempts to read ../../.env and ~/.ssh/id_rsa were blocked in under 40 ms.
A paused project returned HTTP 423 before the request reached Google, preventing spend entirely.
Four alerts were generated automatically with the observed value, threshold, and detector version attached.

Those policy decisions landed between 34.6 and 39.1 ms, far below RunGuard's documented 500 ms p95 target.

The part we are most proud of is less visible: none of those decisions depend on an LLM deciding whether to behave consistently.

What we learned

Building RunGuard reinforced a counterintuitive lesson about AI products:

Sometimes the responsible use of AI is knowing exactly where not to use AI.

Agents are extremely good at reasoning over ambiguity. They are much less appropriate for decisions that need strict reproducibility: whether money can be spent, whether a credential can be accessed, or whether an operation is authorized.

We also learned that observability should not be something added after autonomy. Once software can operate without a person watching it, the decision log becomes part of the product itself.

Customers should be able to answer:

What happened? Why did it happen? What threshold was crossed? Which rule made the decision?

Autonomy without that audit trail is difficult to trust.

What's next for RunGuard

The immediate next step is moving the evidence from a controlled fixture capture to continuous operation against a deployed Cloud Run instance and a real Gemini account, then re-capturing the same autonomous decisions from production logs.

From there, the goal is to put RunGuard in front of real teams already experimenting with Gemini Managed Agents and learn which failures actually scare them enough to require a policy.

Each real failure becomes another deterministic guardrail.

The longer-term vision is simple:

Small teams should be able to run autonomous agents with the same cost controls, policy enforcement, and auditability that today require an internal platform team.

The models are becoming autonomous.

RunGuard is the seatbelt.

See every loop. Stop every runaway.