Uumi

Uumi rotates credentials with agents that never see the secret.

Comment

What inspired us

Earlier this year, Vercel disclosed a security incident that originated with a compromised third-party AI tool used by a Vercel employee. The incident put production credentials in the exposure set. We had to treat our production keys as exposed and rotate them across the services that depended on them.

The rotation itself was more difficult than generating a replacement key. We had to identify every consumer, update each binding, deploy the new generation, verify that real workloads could use it, revoke the old credential, and preserve enough evidence to explain what happened. The work crossed several systems and required careful ordering. Revoking too early could break production. Revoking too late could leave an exposed credential active.

That experience exposed a larger problem. Credential rotation is still treated as a manual incident checklist even though it involves durable state, provider APIs, secret stores, deployments, workload identities, approvals, and recovery. One missed consumer or one ambiguous retry can turn a security response into an availability incident.

At the same time, models are becoming more capable. They can reason over larger contexts, call more tools, and operate across more systems. That increases the blast radius of any credential that enters a model context. We wanted the benefits of agent reasoning without giving agents access to the credentials they were helping rotate.

That led to a simple question:

What if an agent could coordinate credential rotation without ever seeing the secret?

Uumi is our answer.

What we built

Uumi is an agentic credential-rotation platform whose agents never receive plaintext credential values.

A rotation starts from either a signed exposure event or an authenticated operator request. Uumi creates one fenced run for the credential and moves it through twelve durable stages:

Trigger -> Preflight -> Plan -> Create -> Store -> Deploy -> Verify -> Rollout -> Observe -> Approval -> Revoke -> Complete

The stages are not just labels in a workflow. Each stage has a persisted state, a revision, a lease, a fencing token, an attempt record, and evidence. The next stage cannot commit until the current stage has passed its gate.

During Preflight, Uumi checks the credential inventory, declared consumers, workload identities, control policy, and verifier definitions. During Plan, an agent selects the permitted strategy and fixes the recovery branches before any mutation occurs.

Create and Store support two execution paths.

For API-managed providers, the MCP broker validates the run, capability, target resource, lease, and fence before calling the provider connector. The provider creates the replacement credential and returns a one-time value. That value moves directly from the provider connector into Secret Manager. The model receives only metadata and typed results.

For dashboard-only providers, Uumi runs a published browser playbook inside an isolated browser worker. The browser agent proposes bounded actions against the playbook. The worker validates the proposal and executes it through a separate signed request. If the provider displays a one-time credential in the browser, Secure Capture transfers it directly to Secret Manager while model visibility and recording are paused.

After creation, Uumi writes one exact Secret Manager version and binds that version to the rotation generation. It deploys a candidate runtime at zero traffic, verifies the provider, secret version, candidate revision, and consumer access, and only then begins rollout.

Verification uses the real workload identities. Uumi does not merely confirm that a secret exists. It proves that each declared consumer can access the exact replacement version under its own service account. After rollout, generation-scoped probes observe the new revision before the run can proceed.

Revocation is treated as a separate protected action. For API providers, Uumi proves that authentication with the predecessor is rejected. For browser-managed providers, it executes and verifies the published revoke checkpoint. If policy requires approval, the operator authorizes the exact action bound to the current run, generation, plan, and fence.

Completion requires more than a successful provider call. Uumi requires provider-side revocation evidence, retirement of the old Secret Manager version, final audit evidence, incident resolution where applicable, and release of the credential lock.

How we built it

We built Uumi with the Google Agent Development Kit (ADK) and Gemini 3.7 Flash on Vertex AI.

The agent fleet has four specialised roles:

  • The Inventory Agent checks declared consumers, bindings, identities, and coverage.
  • The Planner Agent selects a permitted rotation strategy and produces recovery proposals.
  • The Browser Playbook Agent creates bounded browser procedures for providers without suitable APIs.
  • The Console Operator Agent coordinates browser actions and returns typed proposals.

The agents reason over redacted, run-bound facts. They do not hold provider credentials, Secret Manager values, unrestricted browser sessions, or arbitrary mutation tools.

Google Cloud Workflows carries the long-running operation across hours or days. Cloud Run hosts the API, incident ingestion, coordinator, MCP broker, outbox publisher, notification worker, and audit publisher. Firestore stores the run state, revisions, leases, fencing tokens, immutable bindings, plans, approvals, attempts, and state transitions.

Secret Manager stores immutable credential versions. Pub/Sub and Eventarc deliver committed events. Transactional outboxes separate state commits from message delivery, so a delivery failure does not erase a successful state transition.

The MCP broker is the mutation boundary for API providers. It validates every call against the current run, published control version, capability, resource, lease, and fence. Browser actions use a separate Compute Engine worker with no public IP, a default-deny egress path, and Secure Capture for one-time values.

The client is served through Firebase Hosting. Operators authenticate through Firebase Authentication and access protected browser sessions through IAP. Evidence and telemetry are written through redaction-safe logging and tracing paths.

The policies that govern execution are immutable. ControlVersion fixes allowed tools, protected actions, checks, observation limits, and recovery policy. PlaybookVersion fixes browser objectives, selectors, checkpoints, declared fields, and capture metadata. ProbeVersion fixes verifier targets and success conditions. RotationPlan fixes the strategy, consumers, rollout milestones, observation duration, and recovery identities.

Agents can reason about these objects, but execution uses the exact published versions bound to the run.

Challenges we faced

The first challenge was the secret boundary. It is easy to say that an agent should not see a credential. It is harder to guarantee that the value does not appear in prompts, tool results, logs, traces, browser recordings, or temporary state.

We therefore designed the transfer path first. API-created values move directly from the provider connector to Secret Manager. Browser-disclosed values pass through Secure Capture while model visibility and recording are paused. Connectors return fingerprints, identifiers, version names, and status—not plaintext.

The second challenge was coordinating several generations of state. A credential can have a provider identity, multiple Secret Manager versions, several Cloud Run revisions, many consumers, and an active exposure incident. Every stage must refer to the same target generation. Otherwise, a late retry can update the wrong consumer or revoke the wrong predecessor.

The third challenge was partial failure. A provider can successfully create a credential while Uumi times out before receiving the response. A worker can lose its lease while the provider call is still in progress. A retry can create a second candidate. We could not solve these cases by blindly repeating the last request.

Uumi reconciles before retrying. It compares the provider and Secret Manager against pre-mutation baselines, identifies whether a candidate belongs to the timed-out attempt, removes an orphan only when attribution is safe, and retries under a new fence. Stale workers cannot commit because every write must match the current revision, lease, and fencing token.

Approval created another boundary. Revocation cannot be hidden inside a broad “continue” decision. The approval must authorize one exact protected action, against one generation and one plan, before expiry. A resumed run receives a renewed fence and cannot reuse an earlier approval outside its original scope.

Finally, we had to support providers that do not expose reliable APIs. Browser automation cannot be treated as unrestricted computer control. Uumi uses immutable playbooks, declared selectors, checkpoints, output schemas, isolated browser workers, signed proposals, and explicit approval gates.

What we learned

We learned that agentic automation is not about giving agents more authority. It is about giving them enough context to reason while keeping authority in deterministic, auditable services.

The model can assess inventory, choose among permitted strategies, produce a browser playbook, or propose a recovery action. It cannot retrieve the secret, invent a new capability, widen the consumer set, bypass a fence, or revoke a credential outside the published plan.

We also learned that durable state is part of the product. A rotation that works only when every request returns on time is not reliable automation. The system must explain what happened after a timeout, a duplicate event, an expired lease, a rejected approval, a provider-side success, or a partial browser session.

The final lesson is that secure credential rotation is a proof problem. Uumi does not stop after creating a replacement. It proves that the replacement is stored, bound to the correct consumers, deployed safely, accepted by real workloads, observed under traffic, and followed by provider-side rejection of the predecessor.

That is the standard we wanted from Uumi: agents can reason about the operation, but the credential remains outside the model.

Built With

Share this project:

Updates

Submission history