Audience: Enterprise architects deploying Gemini agents on Google Cloud, compliance officers mapping agent governance to regulatory frameworks, security teams evaluating Agent Gateway and Model Armor, auditors verifying AI agent accountability evidence.
1. What Google Built
Complementary, not competitive. Google governs agent operations inside its trust boundary. SWT3 provides independent witness evidence from outside it. Platform teams use the Govern pillar to enforce policy. Compliance teams use SWT3 to demonstrate to auditors that governance was in effect at a specific point in time. The two layers serve different stakeholders with different requirements.
Google Cloud announced the Gemini agent at Gemini at Work 2026 (October 8, 2026) as a universal agent for enterprise work -- knowledge tasks, content creation, coding, and multi-step execution across an organization's applications and data. The agent runs on the Gemini Enterprise Agent Platform, organized into four pillars: Build, Scale, Govern, and Optimize.
Three features carry specific compliance implications:
- Coworker Agents receive persistent organizational identities -- their own
@agents.company.comemail, calendar, and Drive storage. They persist across sessions and operate autonomously after a user closes their device. - Smart Routing selects between Gemini and Anthropic Claude models per task based on requirements, performance, and cost. A single agent session may span multiple foundation models with no external record of which model handled which decision.
- Persistent Memory spans four types: session (current task), semantic (learned knowledge), procedural (self-written workflows), and episodic (full action history). Agents that write their own procedures and then execute them operate in a fundamentally different risk category than agents running pre-defined workflows.
The platform integrates with Google Workspace, Microsoft 365, Slack, Salesforce, ServiceNow, and Jira. Tools connect via Model Context Protocol (MCP) servers.
The Govern Pillar
Google built a well-engineered governance stack: Agent Identity (SPIFFE-based cryptographic IDs with auto-provisioned X.509 certificates), Agent Registry (catalog of approved agents, tools, and MCP servers), Agent Gateway (network-layer policy enforcement with default-deny), Model Armor (content security filtering for injection, leakage, and harmful content), Semantic Governance Policies (natural language constraints on tool calls), and Agent Sandbox (isolated code execution). Agent Gateway and Model Armor are generally available. Semantic Governance remains in Preview.
Organizations operating below the regulatory threshold for independent evidence may find the Govern pillar sufficient on its own. For regulated workloads -- healthcare, financial services, EU AI Act high-risk systems, GPAI providers -- the question is not whether Google's governance is well-built. It is whether the evidence of that governance can withstand independent scrutiny.
2. The Evidence Layer
The Gemini Enterprise Agent Platform's Govern pillar provides strong operational governance: Agent Identity assigns each agent a SPIFFE-based cryptographic ID with auto-provisioned X.509 certificates. Agent Gateway enforces a default-deny model on all agent traffic. Model Armor inspects prompts and responses for injection attacks, harmful content, and data leakage. These are well-engineered enforcement controls.
Compliance evidence is a separate concern. When an auditor asks "prove that Agent Gateway was enforcing your access policy on Tuesday at 14:00," the platform's Cloud Audit Logs record that the agent acted. What they do not produce is an independent, cryptographically verifiable attestation that the governance control was in effect -- one that originates from outside Google's infrastructure and cannot be retroactively modified by the platform operator.
This is not a limitation unique to Google. Any platform where the infrastructure provider, the model vendor, and the governance layer are the same organization faces the same structural challenge: the entity attesting to compliance is also the entity being evaluated. An independent evidence layer addresses this by producing witness records from outside the trust boundary.
The SWT3 protocol provides this evidence layer. Each governance event -- an identity provisioning, a gateway policy evaluation, a guardrail activation -- can produce an immutable SWT3 Witness Anchor with a verifiable fingerprint, creating the kind of independent compliance evidence that regulated workloads require.
3. The Three-Layer Stack
Google Agent Platform
Agent Gateway, Agent Identity, Model Armor, Agent Sandbox. Governs agent operations in real time.
SWT3 Protocol
Witness anchors, fingerprints, clearing levels. Produces independent compliance evidence.
Auditors / Notified Bodies
Verify anchors, check policy hashes, validate observation windows. Independent evaluation.
Each layer operates independently. Enforcement continues if the evidence layer is unavailable. Evidence records remain verifiable without enforcement running. Assessment can occur offline from either layer.
4. Platform Governance Mapped to SWT3
| Google Component | What It Does | SWT3 Procedure | Why Independent Evidence |
|---|---|---|---|
| Agent Identity | SPIFFE IDs, X.509 certs, mTLS + DPoP token binding | AI-ID.1 | Google issues the identity and attests to it. An auditor needs a record from outside the issuing authority. |
| Agent Registry | Catalog of agents, tools, MCP servers, A2A Agent Cards | AI-MCP.1 | Registry contents can change. A witness anchor proves which tools were approved at a specific point in time. |
| Agent Gateway (ingress) | Client-to-agent policy enforcement, default-deny | AI-ACC.1 | Cloud Audit Logs show the agent acted. They do not prove the policy was evaluated before it acted. |
| Agent Gateway (egress) | Agent-to-tool/API policy enforcement, MCP attribute auth | AI-TOOL.1 | Tool call logs can be rotated or filtered. A witness anchor is an immutable record of every tool invocation. |
| Model Armor | Prompt/response filtering for injection, leakage, harm | AI-GRD.1, AI-GRD.2 | An auditor needs proof the filter was active during the operation, not just that it exists in the configuration. |
| Semantic Governance | Natural language policy constraints on tool calls | AI-GOV.1 | Policies can run in DRY_RUN mode (log but don't block). A witness anchor records whether enforcement was real. |
| Agent Observability | OTel traces, logs, metrics, latency, token usage | AI-AUDIT.1 | Operational telemetry can be deleted. A witness anchor proves the telemetry existed and was complete. |
5. Procedure Deep Dives
Agent Identity Witnessing
Records that an agent's cryptographic identity was properly provisioned and that credentials were bound to the agent's operations. In the Gemini context, this witnesses the SPIFFE ID assignment, X.509 certificate provisioning (24-hour validity, auto-rotated), and mTLS/DPoP token binding that prevents credential theft.
| Factor A | agent_id -- the agent's unique identifier (SPIFFE URI or application-level ID) |
| Factor B | identity_provider -- the system that issued the identity (e.g., Google Agent Identity) |
| Factor C | credential_type -- the binding mechanism (X.509, mTLS, DPoP) |
| Verdict | PASS when identity is valid and credentials are properly bound |
Verify that the agent_id in the witness anchor matches the SPIFFE URI assigned by Google Agent Identity. Cross-reference the anchor timestamp with the X.509 certificate validity window to confirm the identity was active during the witnessed operation. For coworker agents, verify the identity persists across sessions by checking multiple anchors for the same agent_id.
Access Authorization Witnessing
Records that a pre-inference authorization check occurred before an agent accessed a resource or executed an action. In the Gemini context, this witnesses Agent Gateway's default-deny policy evaluation -- the IAM condition check that determines whether an agent is permitted to reach a specific tool, API, or data source.
| Factor A | authorization_id -- the policy or IAM condition evaluated |
| Factor B | decision -- permit or deny |
| Factor C | resource_scope -- the target resource or endpoint |
| Verdict | PASS when authorization check completed (regardless of permit/deny outcome) |
Look for both PASS and FAIL verdict anchors. A pattern of denied access attempts indicates the default-deny model is active and enforcing boundaries. Verify that the authorization_id references a specific IAM policy rather than a wildcard. For Agent Gateway egress, cross-reference the resource_scope with the Agent Registry to confirm the target was an approved destination.
Tool Call Witnessing
Records each tool invocation that an agent makes through Agent Gateway's egress path. In the Gemini context, this witnesses MCP tool calls, A2A delegations, and API requests that pass through the gateway's attribute-based authorization layer.
| Factor A | tool_name -- the tool or MCP server invoked |
| Factor B | duration_ms -- execution time in milliseconds |
| Factor C | scope -- the authorization scope granted for this call |
| Verdict | PASS when the tool call completed within its authorized scope |
Request the witness ledger filtered by tool_name to see the full inventory of tools an agent has called over a given period. Compare this against the Agent Registry's approved tool list. Any tool call not in the registry is a finding. For MCP-specific calls, verify that the gateway parsed MCP attributes and applied attribute-based authorization rather than allowing unrestricted pass-through.
Guardrail Attestation
Records that a content security guardrail was active during an agent's operation. In the Gemini context, this witnesses Model Armor's prompt and response filtering -- whether it detected and blocked injection attempts, harmful content, or data leakage.
| Factor A | guardrail_type -- the filtering category (injection, harmful content, data leakage) |
| Factor B | policy_active -- 1.0 if the guardrail was in effect, 0.0 otherwise |
| Factor C | blocked_count -- number of items blocked during the observation window |
| Verdict | PASS when the guardrail was active (regardless of whether it blocked anything) |
The critical evidence is not whether Model Armor blocked a threat -- it is whether Model Armor was active. A PASS verdict with blocked_count of zero is normal and demonstrates continuous protection. A FAIL verdict (guardrail inactive) during a production operation is a finding. Verify the guardrail_type covers all three categories: injection, harmful content, and data leakage.
Guardrail Drift Detection
Records whether the guardrail configuration has changed since the last attestation. In the Gemini context, this detects when Model Armor policies or filter sensitivity levels have been modified, intentionally or otherwise.
| Factor A | config_hash -- SHA-256 of the current guardrail configuration |
| Factor B | previous_hash -- SHA-256 of the previously attested configuration |
| Factor C | drift_detected -- 1.0 if hashes differ, 0.0 if unchanged |
| Verdict | PASS when configuration matches previous attestation. FAIL when drift detected. |
Guardrail drift is not inherently a failure -- organizations change configurations intentionally. The compliance question is whether the change was authorized. When drift is detected, cross-reference the anchor timestamp with change management records. Unauthorized drift during a production window is a finding. Authorized drift with a corresponding change ticket is expected operational behavior.
Model Card Witnessing
Records which foundation model handled a specific operation. In the Gemini context, this is critical because Smart Routing dynamically selects between Gemini and Claude models per task. Without independent witnessing, there is no external record of which model made which decision.
| Factor A | model_id -- the specific model version used (e.g., gemini-2.5-pro, claude-sonnet-4-6) |
| Factor B | provider -- the model provider (Google, Anthropic) |
| Factor C | routing_reason -- why Smart Routing selected this model |
| Verdict | PASS when model identity is recorded |
For regulated workloads, verify that every inference has a corresponding AI-MDL.2 anchor identifying the model. When Smart Routing switches models mid-task, look for sequential anchors showing the transition. This is especially important for EU AI Act Article 12 record-keeping, which requires documenting which AI system produced which output.
Decision Chain Witnessing
Records the sequence of decisions an agent makes across multiple steps, tools, and models. In the Gemini context, this captures the full provenance of a multi-step task where the agent plans, delegates to sub-agents, calls tools through MCP, and produces output -- potentially spanning both Gemini and Claude models in a single chain.
| Factor A | chain_id -- unique identifier for the decision sequence |
| Factor B | step_count -- number of steps in the chain |
| Factor C | model_count -- number of distinct models involved |
| Verdict | PASS when the full chain is captured with no gaps |
Decision chains are the primary evidence artifact for multi-agent workflows. Verify that the step_count matches the expected workflow length. A chain with gaps (missing steps) indicates incomplete witnessing. For coworker agents running long-duration tasks, look for chains that span multiple days and verify continuity across session boundaries.
Audit Trail Witnessing
Records that audit telemetry was collected and preserved as independent evidence. In the Gemini context, this witnesses OpenTelemetry traces, logs, and metrics emitted by Agent Gateway, Model Armor, and Agent Runtime -- converting operational telemetry into cryptographically verifiable compliance evidence.
| Factor A | telemetry_source -- the component emitting telemetry (gateway, armor, runtime) |
| Factor B | event_count -- number of telemetry events in the observation window |
| Factor C | completeness -- 1.0 if no gaps detected, fractional if events are missing |
| Verdict | PASS when telemetry is complete and hashed. FAIL when gaps detected. |
The distinction between operational telemetry and compliance evidence is retention and immutability. Operational OTel traces can be rotated, filtered, or deleted. A SWT3 witness anchor for the same telemetry window creates an independent record that the telemetry existed and was complete at a specific point in time. If the telemetry is later deleted, the anchor remains as evidence of what was collected.
Governance Framework Witnessing
Records that a governance policy was evaluated before an agent action proceeded. In the Gemini context, this witnesses Semantic Governance Policy evaluations -- the natural language constraints that control how agents use tools and data. Also applies to IAM Unified Access Policies and Custom Authorization Engine delegations.
| Factor A | policy_type -- the governance mechanism (semantic, IAM, custom auth engine) |
| Factor B | evaluation_result -- the policy verdict (allow, deny, dry_run) |
| Factor C | policy_version -- hash or version of the policy evaluated |
| Verdict | PASS when the governance evaluation completed |
Semantic Governance is currently in Preview on Google Cloud. If the organization relies on it for compliance, verify that production deployments are not running in DRY_RUN mode. DRY_RUN evaluations log policy violations but do not block the action. Look for the evaluation_result to confirm enforcement mode. Also note that Model Armor and Semantic Governance cannot be combined on the same ingress gateway -- verify which is active on each gateway instance.
Memory Context Witnessing
Records that an agent's memory operations were witnessed during task execution. In the Gemini context, this captures reads and writes across the four memory types: session, semantic, procedural, and episodic. This is particularly important for coworker agents that maintain persistent memory across multiple sessions and days of operation.
An agent that writes its own procedural memory -- creating workflows it then executes autonomously -- is operating in a fundamentally different risk category than an agent following pre-defined instructions. The memory itself becomes a compliance artifact that may require independent evidence of when it was created, what it contains, and whether it was modified.
| Factor A | memory_type -- which memory was accessed (session, semantic, procedural, episodic) |
| Factor B | operation -- read or write |
| Factor C | context_hash -- SHA-256 of the memory content accessed |
| Verdict | PASS when memory operation is witnessed |
Procedural memory is the highest-risk memory type from a compliance perspective -- it stores learned workflows that the agent created itself. Verify that procedural memory writes are witnessed before the agent uses them in production. Compare the context_hash across sequential anchors to detect unauthorized memory modifications. For regulated environments, episodic memory (the agent's full action history) may itself constitute a compliance record that requires retention guarantees.
6. Regulatory Framework Mapping
The following table shows how the combined Google + SWT3 stack maps to specific regulatory requirements. Google provides the enforcement. SWT3 provides the evidence. For deeper coverage of individual frameworks, see the dedicated crosswalk guides for EU AI Act, NIST AI RMF, ISO 42001, OWASP Agentic Top 10, and GPAI Code of Practice.
| Framework | Citation | Requirement | Google Component | SWT3 Evidence |
|---|---|---|---|---|
| EU AI Act | Art. 9(2)(a) | Implement technical measures to manage risks of high-risk AI systems throughout their lifecycle | Agent Gateway, Model Armor | AI-GRD.1, AI-ACC.1 |
| EU AI Act | Art. 12 | High-risk AI systems shall allow automatic recording of events (logs) throughout their lifetime | Agent Observability (OTel) | AI-AUDIT.1 |
| EU AI Act | Art. 17 | Providers shall establish a quality management system documenting policies, procedures, and instructions | Agent Registry, governance policies | AI-GOV.1, AI-MCP.1 |
| EU AI Act | Art. 26 | Deployers shall keep logs automatically generated by the high-risk AI system, to the extent they are under their control | Cloud Audit Logs | AI-CHAIN.1, AI-MDL.2 |
| NIST AI RMF | GOVERN 1.2 | Processes and procedures to address AI risks are defined, documented, and integrated into organizational governance | Semantic Governance | AI-GOV.1 |
| NIST AI RMF | MAP 3.4 | Relevant AI actors and their interactions are mapped, including third-party components | Agent Identity, Agent Registry | AI-ID.1, AI-MCP.1 |
| NIST AI RMF | MEASURE 2.6 | AI system performance and trustworthiness are measured in deployment and monitored regularly | Agent Observability | AI-AUDIT.1 |
| NIST AI RMF | MANAGE 2.3 | Identified risks are prioritized and treated within acceptable tolerances using documented controls | Model Armor, Agent Sandbox | AI-GRD.1, AI-GRD.2 |
| ISO 42001 | A.6.2.6 | The organization shall ensure integrity of AI systems and their components throughout the lifecycle | Agent Identity, Agent Gateway | AI-ID.1, AI-ACC.1 |
| OWASP Agentic | #1 (ASI01) | Prevent manipulation of agent objectives through prompt injection, context poisoning, or goal substitution | Semantic Governance, Model Armor | AI-GRD.1, AI-GOV.1 |
| OWASP Agentic | #3 (ASI03) | Prevent agents from invoking tools beyond their authorized scope or in unintended sequences | Agent Gateway egress, Agent Registry | AI-TOOL.1, AI-MCP.1 |
| GPAI CoP | Measure 7 | Providers of GPAI models shall document and make available information about the model used to generate outputs | Smart Routing logs | AI-MDL.2 |
7. Coverage Matrix
SWT3 witness procedures mapped to Google platform components. A "Y" indicates the procedure produces independent evidence for that component's operations.
| Procedure | Identity | Registry | Gateway | Model Armor | Sem. Gov | Observability | Sandbox |
|---|---|---|---|---|---|---|---|
| AI-ID.1 | Y | ||||||
| AI-ACC.1 | Y | Y | |||||
| AI-TOOL.1 | Y | Y | |||||
| AI-MCP.1 | Y | Y | |||||
| AI-GRD.1 | Y | ||||||
| AI-GRD.2 | Y | ||||||
| AI-GOV.1 | Y | ||||||
| AI-MDL.2 | Y | ||||||
| AI-CHAIN.1 | Y | Y | |||||
| AI-AUDIT.1 | Y | Y | Y | Y | Y | ||
| AI-SKILL.2 | Y | Y |
8. Code Examples
Python: Witness a Gemini Inference
from swt3_ai import Witness
from google import genai
witness = Witness(
api_url="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
agent_id="coworker-finance-analyst"
)
client = genai.Client()
wrapped = witness.wrap(client)
# Every call through wrapped client is independently witnessed
response = wrapped.models.generate_content(
model="gemini-2.5-pro",
contents="Summarize Q3 revenue by region"
)
# Smart Routing: if the agent switches to Claude, SWT3 records
# which model handled the task via AI-MDL.2
TypeScript: Witness a Gemini Inference
import { Witness } from "@tenova/swt3-ai";
import { GoogleGenerativeAI } from "@google/generative-ai";
const witness = new Witness({
apiUrl: "https://sovereign.tenova.io/api/v1/witness",
apiKey: "axm_live_...",
agentId: "coworker-finance-analyst"
});
const genAI = new GoogleGenerativeAI(process.env.GOOGLE_API_KEY);
const model = genAI.getGenerativeModel({ model: "gemini-2.5-pro" });
const wrapped = witness.wrapTool(model, "gemini-generate");
// Every call is independently witnessed
const result = await wrapped.generateContent(
"Summarize Q3 revenue by region"
);
9. For Auditors
| Examiner Question | Where to Look |
|---|---|
| "How do I know which model produced this output?" | AI-MDL.2 anchors show the model ID and provider for each inference. Filter by chain_id to trace multi-model tasks. |
| "Was the access policy enforced when this agent ran?" | AI-ACC.1 anchors record every Gateway policy evaluation. Look for the authorization_id referencing the IAM condition. |
| "Is the content filter still configured the same as last audit?" | AI-GRD.2 anchors compare configuration hashes. No drift = identical hashes across attestation windows. |
| "Can the agent access data it shouldn't?" | AI-TOOL.1 anchors show every tool call with scope. Compare against Agent Registry approved list. |
| "How do I verify these records weren't altered?" | Each SWT3 Witness Anchor contains a SHA-256 fingerprint that any party can independently recompute and verify. Paste the anchor token at sovereign.tenova.io/verify or use the protocol verifier. |
| "What happens when the agent remembers something?" | AI-SKILL.2 anchors record memory operations by type. Procedural memory writes are the highest-risk category. |
| "Does this evidence meet EU AI Act Article 12?" | Combine AI-AUDIT.1 (record-keeping) + AI-MDL.2 (model identification) + AI-CHAIN.1 (decision provenance) for a complete Article 12 evidence package. |
10. Clearing Level Behavior
SWT3 clearing levels classify the sensitivity of witnessed operations. For Gemini Enterprise workloads:
| Level | Classification | Gemini Use Case | Evidence Handling |
|---|---|---|---|
| L0 | Analytics | Internal productivity (email drafts, slide generation, meeting scheduling) | Aggregate telemetry, no PII in factors |
| L1 | Standard | Business operations (report generation, data analysis, code review) | Full factor detail, standard retention |
| L2 | Sensitive | Customer data processing (support cases, financial analysis, HR workflows) | Encrypted factors, restricted access, extended retention |
| L3 | Classified | Regulated workloads (healthcare, financial services, defense) | Full chain-of-custody, jurisdiction controls, legal hold capable |
Clearing levels are set per witness call. An organization running both internal productivity agents (L0) and customer-facing financial agents (L2) applies different evidence handling to each without changing the enforcement layer.
11. Multi-Model and Coworker Agent Considerations
A Scenario: What One Agent Task Looks Like
A coworker agent receives an email asking it to prepare a quarterly revenue analysis. Here is what happens and what the witness chain captures:
| Step | What Happens | Witness Anchor |
|---|---|---|
| 1 | Agent authenticates via SPIFFE identity, Gateway evaluates IAM policy | AI-ID.1, AI-ACC.1 |
| 2 | Smart Routing selects Gemini for data analysis, calls BigQuery via MCP | AI-MDL.2 (model=gemini-2.5-pro), AI-TOOL.1 (tool=bigquery-mcp) |
| 3 | Model Armor scans the response for data leakage before returning results | AI-GRD.1 (guardrail_type=data_leakage) |
| 4 | Smart Routing switches to Claude for narrative writing | AI-MDL.2 (model=claude-sonnet-4-6, provider=Anthropic) |
| 5 | Agent writes the analysis to a Google Doc and stores the workflow in procedural memory | AI-SKILL.2 (memory_type=procedural, operation=write) |
| 6 | Full decision chain recorded with all steps linked | AI-CHAIN.1 (step_count=5, model_count=2) |
Without independent witnessing, the only record of steps 2 and 4 -- which model handled which part of the analysis -- exists inside Google's operational logs. The witness chain creates a verifiable evidence trail that an auditor can inspect independently of the platform.
Coworker Agent Identity
Coworker agents receive persistent organizational identities that span sessions, days, and model switches. The agent_id in SWT3 anchors maps to the coworker's identity, creating a continuous evidence trail. This is especially valuable when a coworker agent operates autonomously after the requesting user has closed their device -- the witness record proves what the agent did while no one was watching.
Cross-Tenant Boundary
Google's Agent Identity trust stops at the tenant boundary by design. Agent Registry is tenant-scoped. Cross-tenant agent interactions require external protocols (A2A, ERC-8004). SWT3 witness anchors are tenant-scoped as well, but the verification endpoint is public -- any party can verify an anchor's fingerprint without needing access to the originating tenant. This enables cross-organizational evidence sharing without cross-tenant trust dependencies.
12. Get Started
pip install swt3-ai
or npm install @tenova/swt3-ai