Google Cloud details Project Chrysalis, a self-evolving AI agent architecture with four security gates

Google has published Project Chrysalis, a research reference architecture for AI agents that can diagnose infrastructure incidents, generate executable mitigation code, evaluate the consequences of their actions and modify their own multi-agent organization under explicit security controls.

Detailed on October 22, 2026, the architecture combines Gemini, the Agent Development Kit (ADK), BigQuery, Cloud KMS, Model Armor, Binary Authorization, Open Policy Agent and human approval mechanisms into a closed-loop incident-response system.

In Google's demonstration, the system generates a token-bucket rate limiter, validates its code, signs the artifact and mounts it into an API gateway to protect an overloaded database. Google reports first mitigation in 1.8 seconds, elimination of HTTP 5xx errors in a controlled recovery test and P99 latency falling from 519.8 to 18.2 milliseconds.

These are measurements from a simulated Black Friday cache-stampede workload, not independently established outcomes from customer production systems. Project Chrysalis is an implemented reference demonstration, not a generally available standalone commercial product.

··········

WHAT PROJECT CHRYSALIS ACTUALLY IS.

Project Chrysalis is an implemented reference architecture for governed self-evolving AI agents, not a newly trained foundation model. The demonstration uses Gemini 4 Argon through ADK with monitoring, tool execution, policy enforcement, memory, simulation and approval workflows.

Google organizes the design around diagnosis, mitigation generation, intervention evaluation, operational memory and controlled restructuring of the agent hierarchy. The model does not independently decide that its generated code is safe to execute.

........

Component	Function
Gemini 4 Argon	Incident reasoning
Google ADK	Agent orchestration
APEX	Hotpatching and adaptation
AgentEvolver	Outcome attribution
BigQuery	Policy replay
Model Armor	Input screening
Cloud KMS	Artifact signing
OPA	Policy enforcement
Cloud Logging	Audit

........

··········

THE SIMULATED BLACK FRIDAY INCIDENT.

Google's demonstration begins with a checkout service experiencing a burst of concurrent requests. Redis cache misses cause multiple requests to query a Cloud SQL PostgreSQL database simultaneously, producing a cache stampede.

The connection pool has only two active connections. A burst of 50 concurrent requests across 15 cold inventory keys follows five warm-up requests. The cache hit ratio falls to zero, the pool reaches 100% saturation, HTTP 500 errors reach 72.7%–80%, and P99 latency reaches 519.8 milliseconds.

The intentionally constrained two-connection database and 50-request burst make the failure reproducible; these are not measurements of a large retailer's production infrastructure.

........

Measurement	Simulated failure
Concurrent burst	50 requests
Cold inventory keys	15
Database connections	2 of 2 saturated
HTTP 500 errors	72.7%–80%
P99 latency	Up to 519.8 ms

........

··········

WHY RESTARTING THE DATABASE IS THE WRONG RESPONSE.

Restarting the connection pool does not address the cache stampede's cause: too many incoming requests reaching the database after cache misses. It can interrupt work already in progress while leaving the underlying overload unchanged.

Google reports that the restart intervention increased latency to approximately 3,800 milliseconds in the simulated experiment. This negative outcome later informs the agent's intervention evaluation.

The appropriate mitigation regulates admission to the overloaded service rather than repeatedly resetting saturated resources.

··········

AUTONOMOUS TOOL SYNTHESIS AND THE TOKEN-BUCKET HOTPATCH.

The APEX Layer 1 Hotpatch Synthesizer produces an in-memory token-bucket rate limiter. Each accepted request consumes a token, while tokens replenish at a configured rate. Google's initial patch uses capacity 10 and a replenishment rate of 40 requests per second.

Before execution, an Abstract Syntax Tree visitor inspects generated code for prohibited operations, OPA checks operational constraints, Cloud KMS signs the validated artifact, and authorization middleware verifies provenance before mounting the patch into the gateway.

In the recovery burst, Google reports no HTTP 500 errors, P99 latency of 18.2 milliseconds and zero database-pool saturation. However, 40 requests received HTTP 429 throttling responses and 10 were served from warm cache.

The system protected the backend by limiting admission; it did not successfully complete all 50 requests.

........

Measurement	Before	After
HTTP 500 errors	72.7%–80%	0%
P99 latency	519.8 ms	18.2 ms
Pool saturation	100%	0%
Traffic control	Uncontrolled	Token bucket
HTTP 429 responses	—	40

........

··········

APEX ORGANIZES SELF-EVOLUTION INTO THREE LAYERS.

APEX Layer 1 generates temporary executable mitigation tools. Layer 2 retains validated operational lessons as signed memory. Layer 3 proposes structural changes to the multi-agent hierarchy.

The distinction prevents an urgent temporary mitigation from automatically becoming a permanent architectural change. Structural changes require human approval.

........

Layer	Adaptation	Authorization
APEX 1	Temporary patch	Automated gates
APEX 2	Signed memory	Provenance checks
APEX 3	Agent topology	Human approval

........

··········

AGENTEVOLVER EVALUATES WHICH ACTIONS ACTUALLY HELPED.

AgentEvolver uses Shapley-inspired marginal credit to assess interventions against telemetry including P99 latency, HTTP 5xx errors and database-pool saturation.

Google reports a positive credit of +0.97 for the rate limiter, while the database restart receives a negative assessment. This is a controlled attribution example, not proof that the system can infer causality reliably during every complex production incident.

Background traffic, simultaneous interventions and delayed effects can complicate attribution. Incorrect credit could preserve ineffective operational advice.

··········

CRYPTOGRAPHICALLY SIGNED MEMORY AND OPERATIONAL INVARIANTS.

The system derives a reusable principle: avoid restarting databases during cache-eviction stampedes and favor traffic shaping. It signs the principle using Cloud KMS and indexes it in vector memory.

Cryptographic signatures help verify provenance and detect unauthorized changes; they do not make an operational rule universally correct. Long-term deployment would require handling obsolete, conflicting or context-specific rules.

Google's walkthrough does not provide a longitudinal study of this memory-management problem.

··········

THE AGENT CAN MODIFY ITS OWN HIERARCHY WITHOUT REBUILDING CONTAINERS.

After the incident, Chrysalis proposes adding a Traffic Shaping Specialist Agent equipped with rate-limiting, queue-depth and token-replenishment tools.

Google describes an ADK supervisor managing a directed acyclic graph of agents. Following human approval, the topology adapter instantiates the specialist, modifies the active graph and rebinds the ADK runner in memory.

The demonstration reports that this occurs without container restarts or downtime. It does not establish complete persistence and lifecycle management across all production recovery scenarios.

··········

THE FOUR SECURITY GATES THAT CONSTRAIN AUTONOMOUS ACTIONS.

Google separates input and generated-code inspection, cryptographic artifact provenance, policy and human authorization, and auditability into four governance boundaries.

Model Armor screens telemetry; AST inspection checks generated code; Cloud KMS and Binary Authorization middleware verify approved artifacts; OPA enforces operational limits; human approval governs structural changes; and Cloud Logging records decisions.

No individual mechanism guarantees correctness. A valid signature proves provenance, not semantic safety, and a policy engine enforces only its configured constraints.

........

Security gate	Mechanism	Purpose
Input/code	Model Armor, AST	Reject unsafe content
Provenance	KMS, Binary Authorization	Verify signed code
Policy/approval	OPA, HITL	Enforce authorization
Audit	Cloud Logging	Record decisions

........

··········

MODEL ARMOR AND THE PROBLEM OF UNTRUSTED TELEMETRY.

Logs, request metadata and exception messages may contain attacker-controlled instructions. An agent that treats those instructions as trusted could be redirected from incident response to unauthorized actions.

Model Armor screens incoming telemetry before reasoning, while AST validation checks the structure of generated patches. These controls address different stages and do not replace least-privilege permissions, isolation or runtime testing.

The reference demonstration does not publish a comprehensive adversarial evaluation against all prompt-injection or code-generation attacks.

··········

CLOUD KMS AND BINARY AUTHORIZATION ESTABLISH PATCH PROVENANCE.

Google describes signing the validated patch digest with an asymmetric Cloud KMS key using EC_SIGN_P256_SHA256. Authorization middleware verifies the signature before execution.

This separates code generation from permission to execute and provides an auditable record of approved artifacts. Nevertheless, authentic signed code can still contain vulnerabilities if validation is incomplete.

Provenance verification must therefore be combined with substantive code and policy review.

··········

OPA ENFORCES OPERATIONAL CONSTRAINTS BEFORE EXECUTION.

The OPA controller requires a token replenishment rate of at least 10 requests per second. The initial hotpatch uses 40 requests per second and satisfies the rule.

Later, BigQuery counterfactual evaluation selects a candidate with replenishment rate 5 requests per second, below the previously stated minimum. Google does not fully explain whether that candidate operates under another rule set, remains offline or requires an explicit exception.

The candidate should not be described as automatically authorized for production under the same OPA constraint.

··········

HUMAN APPROVAL IS REQUIRED FOR STRUCTURAL SELF-MODIFICATION.

Project Chrysalis treats temporary mitigation differently from modifying the agent hierarchy. A generated patch can execute after automated validation, while a Tier-2 structural update requires dual-custody human-in-the-loop governance.

An authorized site reliability engineer must approve the change before the system receives a cryptographic token and adds the specialist agent. The design supports bounded autonomy, not unrestricted recursive self-modification.

The approval requirement may delay structural evolution, but the immediate mitigation path remains separate.

··········

BIGQUERY EVALUATES 400 COUNTERFACTUAL TRAFFIC POLICIES.

After stabilizing the incident, the system replays request traces against combinations of token-bucket capacities and replenishment rates. Google reports evaluating 400 policies in approximately 0.5 milliseconds using vectorized in-memory replay.

The selected candidate uses capacity five and replenishment rate five requests per second, producing zero HTTP 5xx errors in the simulation. The 0.5-millisecond result is not end-to-end time to gather telemetry, execute a cloud job, deploy a policy or recover an application.

The candidate is optimal only relative to the replayed traffic, tested search space and objective function. Its rate also requires reconciliation with the earlier OPA minimum.

........

Counterfactual metric	Result
Policies evaluated	400
Vectorized replay	~0.5 ms
Selected capacity	5 tokens
Selected refill rate	5 requests/s
Simulated HTTP 5xx	0

........

··········

CHAOS TESTING VALIDATES THE EVOLVED CONFIGURATION IN A SANDBOX.

A Curiosity Chaos Red-Team Agent runs the evolved configuration in an isolated shadow environment. The test purges the cache and generates 200 concurrent requests.

Google reports zero HTTP 500 errors and maximum database load of 13%. This validates the selected synthetic workload, not all cache failures, traffic patterns or adversarial conditions.

Long-duration reliability tests, canary deployments and broader fault injection would still be needed before production adoption.

........

Chaos-test condition	Outcome
Cache	100% purged
Concurrent requests	200
HTTP 500 errors	0
Maximum database load	13%
Environment	Shadow sandbox

........

··········

WHAT THE REPORTED 1.8-SECOND MITIGATION TIME MEANS.

Google reports 1.8 seconds to first mitigation and compares it with a reference manual interval of 15–45 minutes. The test takes place in a predefined demonstration with accessible telemetry and a constrained workflow.

This is not an independently replicated benchmark of production incident resolution. Time to first mitigation differs from complete restoration, validation and incident review.

The zero 5xx rate after mitigation also coincides with deliberate HTTP 429 throttling; protecting the backend does not imply that every checkout request completed.

........

Metric	Reported result
First mitigation	1.8 seconds
Manual comparison	15–45 minutes
HTTP 5xx after hotpatch	0%
P99 after hotpatch	18.2 ms
Counterfactual replay	~0.5 ms

........

··········

SELF-EVOLVING AGENTS ARE NOT SELF-RETRAINING FOUNDATION MODELS.

Project Chrysalis does not show Gemini autonomously changing its neural-network weights. Its adaptation occurs in the application layer: generating tools, retaining operational rules and modifying the orchestration graph.

These changes are more inspectable than updates to model parameters. Operators can review code, audit signed memory and approve topology changes.

The demonstration concerns governed operational adaptation rather than autonomous foundation-model training.

··········

IMPLEMENTATION REQUIREMENTS AND PRACTICAL LIMITATIONS.

Reproducing the architecture requires an instrumented application, structured telemetry, ADK orchestration, relevant Google Cloud services and independent governance enforcement.

Organizations must define authorized operations, escalation rules, execution permissions, resource limits and procedures for failed patches or unavailable dependencies.

The publication does not provide comprehensive production reliability results, standardized operating costs, inference consumption or complete latency breakdowns.

··········

WHAT PROJECT CHRYSALIS ESTABLISHES AND WHAT REMAINS UNPROVEN.

The reference implementation shows that an ADK-based agent can diagnose a simulated incident, synthesize a mitigation, pass validation and cryptographic authorization, apply it and evaluate outcomes.

It can retain signed lessons, propose an approved agent-topology change, compare counterfactual policies and test the evolved configuration in a shadow environment.

The publication does not establish universal production reliability, independent replication, broad adversarial robustness or long-term benefits from accumulated operational memory.

··········

WHY THE ARCHITECTURE MATTERS FOR ENTERPRISE AI AGENTS.

An assistant that summarizes logs is different from an agent that generates and mounts executable middleware. The latter can directly affect service availability and customer requests.

Chrysalis separates the model's capacity to propose interventions from the infrastructure's authority to execute them. Code inspection, cryptographic signatures, policy checks, human approval and audit records are execution requirements rather than after-the-fact safeguards.

The central result is not that AI can resolve every outage in seconds. It is that an agent can generate new operational capabilities while remaining subject to independently enforced boundaries.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org