Governed AI Agents You Can Trust — and Prove
Revka is an audit-first platform for putting AI agents to work safely, from a single builder's laptop all the way to enterprise operations. The big idea is simple: let capable AI agents do real work, but keep them on a leash, and keep a record you can actually prove.
That last word matters. Plenty of tools let agents act. Revka is built so that, afterward, you can show exactly what every agent did — and prove the record wasn't quietly changed.
Real agents, doing real work
Revka orchestrates the AI coding agents people already use — like Claude Code and Codex — inside governed workflows. It also reaches into Google's world in two complementary ways that are easy to mix up, so let's keep them clear.
Google ADK (the Agent Development Kit) is Google's free, open-source toolkit for building AI agents — software that can reason with a model, pick a tool, and take a real action. Using ADK, Revka ships two ready-made "robot coworkers." A coder agent clones a code repository, writes a fix for an issue, runs the project's tests, and opens a pull request. A reviewer agent reads those changes and judges them for correctness, safety, and test coverage. Both think using Google's Gemini model and run on Google Cloud using the cloud's own secure identity — not copied-around passwords or keys. The coder lives on Cloud Run (Google's container hosting) because it needs a real sandbox to run commands; the reviewer can also run on Vertex AI Agent Engine, Google's managed home for reasoning agents, because it only needs to read and think.
The Google Agents CLI is a different thing. It's Google's official command-line tool (named "agents-cli") for the lifecycle of agents on its platform — setting them up, testing, deploying, and publishing them. Revka doesn't replace it or turn it into an agent. Instead, a trusted coding agent can call it as a tightly bounded capability when it needs to perform one of those Google steps.
Here's a useful way to picture it. Google's agents-cli is like the power tools in a workshop. Revka doesn't reinvent the tools; it hands a trusted worker a key that only unlocks an approved set of them, only inside the marked-off work area, with machines set to auto-shut-off after a set time, and with the dangerous "log in / change accounts" switch deliberately disabled so a human has to do that outside the shop. In practice that means: the tool only runs a fixed list of approved commands, stays inside the approved folder, has a time limit, runs with a stripped-down set of safe settings, and is turned off by default until you switch it on. (Revka runs the tool; it does not install or log in for you — that stays in human hands.)
A common language between agents: A2A
Most businesses don't want to be trapped inside one vendor's ecosystem. That's where A2A — Agent-to-Agent — comes in. A2A is an open, vendor-neutral protocol, originally published by Google, that lets one agent discover what another can do and hand it a task, even when the two were built by different teams or companies.
The analogy is a standard business-card-and-purchase-order format every contractor agrees to use. Instead of learning each contractor's private phone system, you read their card to see what they do, send a standard work order, and check back for "in progress / done / failed." Revka is the general contractor: it reads the cards and sends each job to whichever specialist fits.
Concretely, a Revka workflow running on your laptop can reach out over the internet to a specialist agent — like that coder or reviewer hosted on Google Cloud — hand it a real job, and get a structured result back. Because A2A is an open standard, the same workflow that serves a solo builder today can grow into B2B settings where different departments, or even different companies, need their agents to cooperate without bespoke, one-off plumbing.
And the doorways are guarded. When Revka calls a private agent on Google Cloud, it mints a short-lived identity "visitor badge" at the moment of the call, shows it at the door, and never staples that badge into the project binder — no secret tokens are written into your workflow files. Cloud access and the agent's own app access are two separate, independently controlled gates.
The centerpiece: govern it, then prove it
This is where Revka earns the word "trust." Two things work together: controls that keep agents on a leash, and a record that proves what happened.
Keeping agents on a leash. Every agent has an autonomy level — read-only (look but don't touch), supervised (act, but ask a human before risky steps; this is the default), or full (act within the rules). Each agent can be limited to specific tools, specific commands, and a specific folder, so it literally cannot use something it wasn't given. Workflows can include a human approval step that freezes everything until a person clicks Approve or Reject — in the dashboard, or even from Slack or Discord. Agents also build a trust score from their track record: do good work consistently and their access can widen; keep making mistakes and the system automatically tightens the leash. And you can set daily and monthly dollar budgets, so an autonomous loop can't quietly burn through your money — once the budget is exceeded, further work stops.
The reason this is credible is that these rules are enforced by the engine, not merely suggested to the AI in a prompt. A disallowed command is actually blocked. Even at "full" autonomy, the command limits, forbidden folders, and rate limits still apply — full only skips the per-step approval prompt.
You can see this in the shipped coder-and-reviewer workflow: a human must approve before the coder is allowed to push a fix, and again before it's
Keeping agents on a leash. Every agent has an autonomy level — read-only (look but don't touch), supervised (act, but ask a human before risky steps; this is the default), or full (act within the rules). Each agent can be limited to specific tools, specific commands, and a specific folder, so it literally cannot use something it wasn't given. Workflows can include a human approval step that freezes everything until a person clicks Approve or Reject — in the dashboard, or even from Slack or Discord. Agents also build a trust score from their track record: do good work consistently and their access can widen; keep making mistakes and the system automatically tightens the leash. And you can set daily and monthly dollar budgets, so an autonomous loop can't quietly burn through your money — once the budget is exceeded, further work stops.
The reason this is credible is that these rules are enforced by the engine, not merely suggested to the AI in a prompt. A disallowed command is actually blocked. Even at "full" autonomy, the command limits, forbidden folders, and rate limits still apply — full only skips the per-step approval prompt.
You can see this in the shipped coder-and-reviewer workflow: a human must approve before the coder is allowed to push a fix, and again before it's allowed to merge and close the issue. The robots never ship anything on their own authority.
Proving what happened. Revka records security-relevant events — commands run, sign-ins, configuration changes, policy violations, workflow starts and stops, approvals — into an append-only log where each entry carries a fingerprint (a SHA-256 hash) computed from its own contents plus the fingerprint of the entry before it. This chains every record together, like numbered pages where each page reprints the seal of the previous one.
Picture a bank's bound ledger where every page is stamped with a wax seal made from the page's contents and an imprint of the previous page's seal. To fake one page, you'd have to re-make every seal after it — so a single forged entry stands out because the seals stop matching. A built-in verifier re-checks every fingerprint, and the dashboard has a one-click "Verify Chain" button that reports whether the chain is intact and how many entries it checked. (An optional secret-key signature adds a second layer that stops even a sophisticated forger; it's available but off by default.)
Alongside that sits the RunLog — a detailed, per-agent record of everything an agent did during a run: each tool call with its arguments and results, commands and their outcomes, files touched, messages, and errors. Think of it as the teller's detailed notebook of every action that day. It is complete and append-only, though it's a notebook, not the sealed ledger — the cryptographic chaining lives in the security audit log.
Why does this matter to a business? It turns "we think the agent did the right thing" into "we can prove what happened, and prove the record wasn't altered." If an insider or an attacker with file access tries to quietly rewrite history — to hide a risky command or a skipped approval — the chain breaks and the change is detectable. One honest note: this is tamper-evident, not tamper-proof. It doesn't stop someone from editing the file; it makes any edit impossible to hide.
Who it's for
Revka is designed to grow with you. A solo builder can start locally, running governed agents on their own machine. A small team can add human approval gates, tool limits, and spending caps. An enterprise can lean on the full picture: agents running on managed Google Cloud with proper identity, cross-vendor coordination over A2A, and a verifiable audit trail that auditors and reviewers expect before AI agents touch real systems.
The same workflow that starts on a laptop keeps its operational record as it grows into managed, auditable, enterprise-reviewed work. You don't rebuild as you scale — you keep going, with the evidence coming along for the ride.
In short
Revka lets capable AI agents do real work — write code, review it, deploy to Google Cloud, coordinate across vendors — while a human stays in the loop for the risky moments and a tamper-evident record captures it all. Governed agents you can trust, and prove. If that's the kind of confidence you've been waiting for before letting agents loose on real systems, Revka was built for exactly this.