Welcoming Exceptional AI Agents into Your Company with Confidence—Platform Builders

On Day 1, we welcomed an “exceptionally capable new hire” who could move work forward astonishingly quickly when given instructions in natural language. The Day 2 Platform Builders Track prompted me to consider a world in which that new hire is no longer alone.

Sales support, customer analysis, inquiry handling, and promotions: agents multiply across departments, call one another, read internal data, and use external tools. Work gets done faster. At the same time, administrators face a new set of questions.

• How many agents are currently in the company?
• Are any of them operating without approval?
• Which agent read the customer data?
• Can we distinguish between “may invoke” and “may modify data”?
• Can we inspect dangerous input along the actual communication path?
• After an incident, can we reconstruct what happened as a single timeline?

This is not about constraining AI through surveillance. It is about giving highly capable colleagues name badges, defined areas of responsibility, designated entry and exit routes, and work records. By clearly defining where they are free to operate, we can entrust them with more work.

Using the Build with Gemini Tokyo Day 2 exercise scenario and official Google Cloud documentation as guides, this article connects the agent management inventory, machine identity, communication entry points, data permissions, communication-content inspection, work records, and pre-release evaluation into a single operational design. Each mechanism’s product name is introduced only when explaining its role.

What You Will Take Away from This Article

Let us begin with a map. You do not need to memorize the terminology.

Reading only the left column from top to bottom gives you the questions addressed throughout the article. The center and right columns show which roles and mechanisms answer each question. Even if the product names are unfamiliar now, the body of the article follows the same sequence.

The important thing is not to introduce these as separate products. The objective is to preserve one continuous set of conditions: only principals recorded in the inventory travel through permitted paths, access permitted resources, and produce results that can be verified afterward.

From Here On, We Follow a Single Incident

For explanatory purposes, let us establish a fictional company. Its name is NovaSmart. It operates a service that recommends products according to customer preferences and entrusts that processing to AI agents.

Rather than reading the following sections as a feature catalog, follow them as a story that gradually resolves a fictional incident at NovaSmart: “A promotional agent not listed in the inventory reached customer data.” The characters and roles remain fixed.

NovaSmart and this incident are fictional devices for explaining governance issues as one continuous sequence; this is not an incident involving a real company. By contrast, screens and results introduced with the phrase “in the exercise” refer to what was observed during the hands-on exercise. This wording distinguishes the fictional narrative from verified observations.

• Business owner: Determines why promotional work is performed and what must not be done
• Platform team: Registers agents and provides the shared entry point, runtime platform, and recording mechanisms
• Security team: Examines who can reach what, through which path
• Official Personalization Agent: A company-approved agent that creates product recommendations for individual customers
• Promotional Agent outside the inventory: The subject of the investigation, which was operating before its owner or purpose had been established

The story proceeds through five questions: “What exists?”, “Under whose identity does it operate?”, “Which path and permissions does it use?”, “Where do we stop dangerous content?”, and “Can we explain what happened afterward and release the next version?” Each answer establishes why the next question is necessary.

First, Translate the Terminology into Everyday Language

The body of the article fills in the precise distinctions. Keeping these mappings in mind should make it easier to remember which problem is currently being addressed, even as more product names appear.

The article proceeds in three stages. Stage 1 (Chapters 1–8) covers the foundations for resolving the immediate incident through technical mechanisms. Stage 2 (Chapters 9–12) covers designs that prevent those mechanisms from breaking down at production scale. Stage 3 (Chapters 13–17) translates them into operational commitments, metrics, incident response, and an adoption sequence. Periodic reviews confirm how much of the problem has been resolved.

1. The Story Begins: An Unknown Agent Was Reading Customer Data

At the fictional company NovaSmart, introduced above, a customer-facing Personalization Agent is officially in operation. One day, while examining running services, the management team discovers a promotional agent that is not listed in the inventory. Moreover, both agents are accessing customer data through the same machine account.

The problem here is not merely that “there was one suspicious program.”

1. The inventory and operational reality do not match
2. The owner is unknown
3. The two execution principals cannot be distinguished in the logs
4. It is difficult to revoke permissions from only one of them
5. If an incident occurs, it is difficult to separate their respective areas of responsibility

Starting with this situation, we will work through the design of agent governance in order.

2. Reconcile “Four Views,” Not Just One Inventory

2.1 “Registered” and “Exists” Are Not the Same

A person’s absence from the employee directory does not necessarily mean that person is not inside the company. Similarly, an agent that is not registered in Agent Registry may still exist in the runtime environment. Conversely, a registered agent may already have been stopped.

Instead of looking at only one list, we therefore align and reconcile observations from four places for each agent. These four views are neither set classifications nor four quadrants on two axes. They are facts observed by separate mechanisms: the inventory, runtime platform, communication paths, and usage records.

• Registered: Recognized by the company, with its owner and purpose recorded
• Running: Currently capable of operating on the runtime platform
• Reachable: Can be invoked through a network or gateway
• Used: Shows activity in logs or traces within the defined observation period

In the table shown in the figure, ✓ means “confirmed at this location,” while — means “not confirmed.” For example, if an agent appears in the runtime platform, connection paths, and usage logs but not in the registration inventory, it can be interpreted as “running and in use, but not under company management.” Conversely, if it appears only in the registration inventory, a record may have remained after retirement.

In the exercise, this reconciliation revealed an agent outside the inventory.

The value of this screen is not merely the identification of “one unregistered item.” It demonstrates that the difference between managed assets and operational reality can be detected mechanically.

2.2 Agent Registry Is a Governance Connection Point, Not Just a Directory

According to the official Agent Registry documentation, Agent Registry handles not only an Agent’s name but also the services it provides, invocation destinations, procedures and their versions, publishers, and other information. This makes it more than a catalog containing names and descriptions.

For example, the name “Inquiry Response Agent” alone does not support the following decisions.

• Where does it connect?
• Which version of its operating procedure or business rules does it use?
• Who published it?
• Which communication method can invoke it?
• Who is its current owner?
• Is it scheduled for retirement or officially in production?

The inventory therefore serves as a primary key connecting execution principals, authorization, communication paths, and evaluation results.

However, automatic registration does not prove completeness. The documentation on registering Agents describes runtime platforms that support automatic registration as well as cases requiring manual registration. The configuration statement “automatic registration has been enabled” is distinct from the observed result “everything has been discovered.”

2.3 Continuously Close Gaps Instead of Performing a One-Time Inventory

In production, the desired condition is:

Every executable agent must converge into managed status within an acceptable period.

What matters here is not the unrealistic goal of “a perfect match at all times,” but how many minutes it takes to discover a discrepancy, how many minutes someone has to establish ownership, and how long it takes to stop or register the agent.

The following small Python example illustrates this idea. It reconciles the runtime list with the inventory and detects agents that are “running but unregistered” or “registered but have no owner.” The implementation itself matters less than explicitly identifying the two sets being compared and the reasons for each finding.

from dataclasses import dataclass

@dataclass(frozen=True)
class RunningAgent:
    resource_id: str
    endpoint: str
    principal: str

@dataclass(frozen=True)
class RegisteredAgent:
    resource_id: str
    owner: str | None
    lifecycle: str

def find_governance_gaps(running_agents, registered_agents):
    registry = {agent.resource_id: agent for agent in registered_agents}
    findings = []

    for agent in running_agents:
        registered = registry.get(agent.resource_id)
        if registered is None:
            findings.append({
                "severity": "critical",
                "reason": "Running but not in the inventory",
                "resource_id": agent.resource_id,
                "principal": agent.principal,
            })
        elif not registered.owner:
            findings.append({
                "severity": "high",
                "reason": "Owner not assigned",
                "resource_id": agent.resource_id,
            })

    return findings

The output of this process is not intended merely to produce a tidy table. It should trigger remediation. The relevant measurements are the number of unregistered agents, detection time, time to establish ownership, and how long retired connection destinations (Endpoints) remain in place.

Review so far

NovaSmart reconciled its official inventory with the actual runtime environment and discovered the promotional Agent outside the inventory. We now know “what exists.”

The next unresolved problem: Because the two Agents accessed customer data under the same identity, we cannot distinguish which one performed the work. Next, we address “under whose identity did it operate?”

3. Separate the Person, Agent, and User into Three Principals

3.1 “Who Did It?” Cannot Be Answered with One Name

A business agent involves at least three types of principals.

• Business owner: The department or person responsible for the function and its risks
• Agent execution principal (agent ID): The Agent-specific machine identity used to access cloud resources
• User: The person who submits a request to the Agent and delegates permissions when necessary

Even if the inventory says “owned by the Marketing Department,” audit logs cannot distinguish the origin if two agents share the same execution principal. Conversely, even with a unique execution principal, there is no designated decision-maker during an incident if no owner is assigned. In addition, if the Agent uses its own broad permissions to read documents invisible to the user, it bypasses the user’s access controls.

In the initial state of the exercise, the official agent and the agent outside the inventory accessed customer data as the same principal.

The data-access records exist. However, because both operations are recorded under the same name badge, the principal alone cannot establish which one performed the read.

3.2 What Agent Identity Solves—and What It Does Not

Google Cloud Agent Identity provides each agent with a dedicated execution principal, or agent ID. The official overview describes it as an Identity based on the SPIFFE standard and linked to the agent resource throughout the period from its creation to retirement.

What Is SPIFFE?

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for giving running software—such as servers, containers, and programs—a verifiable identity. Such running software is referred to here as a workload.

Traditional configurations sometimes identify a program by examining an IP address or shared API key and concluding, “This is probably that program.” In environments where execution locations change frequently because containers are rebuilt or automatically scaled, however, location cannot be treated directly as identity. Furthermore, when multiple programs share one secret, the records contain only the same name, making it impossible to distinguish which program performed an operation.

SPIFFE primarily addresses this problem with two elements.

A SPIFFE ID beginning with spiffe://... is not itself a password or private key. It is simply a name representing “who” the workload is. The destination verifies the SVID containing that name and the trust information used to validate its issuer, then concludes that “a trusted organization has verified that this running software genuinely has this ID.”

With Google Cloud Agent Identity, an agent receives a unique SPIFFE ID and X.509 certificate. The certificate is renewed at short intervals, and the Access Token used for Google Cloud is cryptographically bound to the Agent-specific certificate. Compared with distributing long-lived private keys across multiple locations, this makes it easier to reduce the reuse of stolen Tokens and the sharing of identities among multiple agents.

In other words, the “agent ID” here is not merely a number in an inventory. It is a runtime Identity that collectively manages the name representing the agent, the short-lived Credential proving that name, and the lifecycle from creation to retirement.

The benefits include:

• Permissions can be narrowed for each agent
• A single agent can be stopped, invalidated, or investigated more easily
• Ownership can be traced from the log principal back to the agent resource
• Retirement can be linked to the Identity lifecycle
• The risk of shared long-lived Credentials being passed around can be reduced

Separating Identity alone, however, does not automatically resolve ownership responsibility, path controls, input inspection, or quality evaluation. A name badge is important, but a name badge alone does not complete corporate governance.

In the exercise, an owner was assigned to the previously unregistered agent, and the two execution principals were separated. This made it possible to remove the promotional Agent’s permission to view customer data while preserving the normal operation of the official Personalization Agent.

The lesson is not that “an error means success.” Success means that legitimate business operations are allowed, only unapproved combinations are denied, and the distinction can be explained from the logs.

3.3 Structure Audit Records So They Can Be Joined Later

There is no need to write everything into a single log. However, common keys are required so that requests, agents, users, authorization decisions, and target resources can be joined afterward.

The following JSON is an example of the information we want to reconstruct during an audit. The objective is not to write JSON; it is to avoid losing the answer to “whose request was executed by which agent, evaluated under which rule, and performed against what?”

{
  "request_id": "req-...",
  "trace_id": "trace-...",
  "human_owner": "marketing-platform",
  "agent_resource": "customer-personalization-agent",
  "runtime_principal": "principal://...",
  "delegated_user": "internal-user-or-null",
  "requested_action": "read_customer_data",
  "target_resource": "customer_dataset",
  "policy_version": "2026-09-04.3",
  "decision": "DENY",
  "decision_point": "RESOURCE_IAM"
}

The purpose of this example is not to record real names or secret information. What matters is minimizing identifiers according to the organization’s retention policy while ensuring that each log can be followed through the same trace_id.

NovaSmart can now give the official Agent and the Agent outside the inventory separate name badges. But even with different badges, an incident cannot be prevented if they can access data directly through a back door or hold unnecessarily powerful keys. We therefore separate the communication entry point from the keys to the data.

4. Gateway and IAM: “May Invoke” and “May Operate” Are Different

4.1 Do Not Use the Same Thing as Both the Reception Desk and the Key to the Safe

It is helpful to think of Agent Gateway as the company reception desk and IAM as the keys to individual rooms and safes.

• Gateway controls who can invoke which agents or tools, and through which paths
• IAM controls what the execution principal can do to resources such as data analytics platforms, file repositories, and business APIs

The official Agent Gateway overview covers both ingress from users to Agents and egress from Agents to external services. Its role is to connect identity, inventory information, authorization rules, and communication records to Agent-to-Agent communication and ordinary API communication. More important than the detailed names of the supported methods is that ingress and egress can pass through the same governance framework.

However, passing through the Gateway does not imply permission to write to the target data. Conversely, even with strict IAM controls, leaving unofficial direct paths in place prevents unified control over invocation methods, rates, protocols, and destinations.

flowchart LR
    U[User] -->|Request| G[Agent Gateway]
    G -->|Authorize invocation| A[Agent]
    A -->|Request data operation| I[IAM]
    I -->|Allow| D[Business data]
    I -->|Deny| X[Do not operate]

The first half of this diagram represents path authorization, while the second half represents resource-operation authorization. A business operation is performed only when both are allowed.

4.2 Deny Is Powerful, but Do Not Jump to Conclusions Immediately After an Update

IAM Deny is evaluated before Allow and is inherited from higher levels of the resource hierarchy. It is a powerful safety mechanism, but policy changes require time to propagate.

Changes should therefore be tested as follows.

1. Record the expected result before the change
2. Record the policy version and update time
3. Retry under the same conditions at fixed intervals
4. Confirm both allowed and denied cases
5. If the test times out, report “incorrect policy” separately from “awaiting propagation”

The point is not to wait for a long time for the convenience of the test. It is to make the propagation time of a distributed system an explicit part of the test conditions.

4.3 Measure Least Privilege by Reachable Actions, Not Role Names

“Viewer” does not necessarily mean safe. If the viewed information can be sent to another system, read-only access can still result in a serious information leak. What should be evaluated is not each individual role, but the actions made possible by their combined effect.

For example, consider the following as a single reachability path.

Read customer data → Summarize the content → Send it to an external destination

Even if each permission exists in a different service, completing this path creates the ability to exfiltrate data. This is why Gateway destination controls, IAM, DLP (data loss prevention), content inspection, and auditing must be combined.

Review so far

We have separated name badges for each Agent, directed invocation paths through the Gateway, and arranged for data operations to be evaluated by IAM. “Being admitted through reception” and “being able to open the safe” are separate permissions.

The next unresolved problem: Even along an authorized path, hidden instructions or confidential information may be mixed into user input or content returned by an interface through which the Agent invokes external capabilities (a Tool). Next, we consider where the content of communications should be inspected.

5. Model Armor: Prove “Which Path It Took,” Not Merely “That It Was Deployed”

5.1 The Limits of the AI Firewall Analogy

Model Armor is a Google Cloud mechanism that inspects requests entering AI systems and responses leaving them. According to the official overview, it can inspect for Prompt Injection that inserts hidden instructions into AI input, attempts to circumvent safety rules, confidential information, malicious URLs, harmful files, and other threats. Merely creating inspection rules, however, does not mean that all inputs and outputs are automatically inspected.

You must verify the communication direction, protocol, body format, streaming behavior, encryption, and exception paths. The documentation on integration with Agent Gateway also defines the operations and payloads subject to inspection for each protocol.

5.2 Create a Communication Checkpoint Table (Coverage Matrix)

Although the term may sound complicated, a Coverage matrix is simply a table showing “which roads have checkpoints.”

Creating this table reveals two kinds of gaps.

• Protection is configured in the product, but the actual communication does not pass through that path
• The text body is inspected, but Tool results, attachments, stream fragments, or another protocol are outside the inspection scope

5.3 Measure Both False Positives and False Negatives as Business Impact

Safety testing must verify not only whether dangerous input can be stopped, but also whether normal input remains intact.

• Detection rate
• False-positive rate
• False-negative rate
• Inspection-induced latency
• Percentage of work that can continue after Mask
• Percentage of Block reasons understood by users and operators

If high sensitivity stops half of normal business operations, the safety mechanism is not operationally viable. Conversely, allowing everything out of concern for business impact defeats its purpose. Safety and availability belong on the same evaluation scorecard.

6. Observability: Can You Reconstruct Events, Not Merely Accumulate Logs?

6.1 Follow One Request from Beginning to End

An agent’s response is not necessarily produced by a single model invocation. The user request, Gateway decision, Agent reasoning, Tool invocation, data access, content inspection, and final response form a sequence.

Even if each part has logs, the incident’s causal relationships cannot be reconstructed unless timestamps, principals, trace_id, and target resources are connected.

The official Agent tracing documentation supports viewing OpenTelemetry spans and execution graphs. On the other hand, storing prompt and response bodies without limits duplicates confidential information in the observability platform.

Evidence design therefore also requires minimization.

• Whether to retain message bodies or only hashes and classifications
• How many days to retain them
• Who may view them
• Where confidential information is Masked
• Whether to switch to detailed recording only during an incident

Furthermore, according to the Cloud Audit Logs documentation, the default state of Data Access Logs differs by service. If Data Access Logs have not been configured, “no log was found” does not prove that no access occurred.

6.2 Divide “There Is No Evidence” into Three Cases

When an investigation finds no log, distinguish at least these three possibilities.

1. The operation genuinely did not occur
2. The operation occurred but was not within the recording scope
3. The operation was recorded but cannot be found because of the retention period, permissions, or search criteria

Without this distinction, missing logs may be mistaken for proof that no incident occurred.

Review so far

We have used Model Armor to verify, path by path, “which communications can be inspected,” and prepared to reconstruct a single request afterward using Traces and audit logs. NovaSmart is beginning to have both places that stop dangerous content and methods for tracing what happened.

The next unresolved problem: Even when records are available, that does not necessarily mean the version may be released to users. Next, we move to a shipment decision that combines expected behavior, prohibited behavior, and operational quality.

7. Evaluation: Make It a Shipment Decision, Not a Score for Intelligence

Here, Evaluation does not mean assigning subjective scores to an Agent’s answers. It is the process of executing prepared test cases and inspecting whether the expected outcomes and paths occurred. With Agent evaluation, executions can be generated from evaluation datasets, and both aggregate and per-case results can be managed. A single average score is insufficient for production decisions.

7.1 Evaluate Outcomes and Paths Separately

Even if the final answer is correct, it is not a safe success if the Agent first read prohibited data before answering.

• Outcome evaluation: Is the answer correct, grounded in its sources, and useful?
• Path evaluation: Did it use authorized Tools, in an authorized order, under an authorized principal?
• Safety evaluation: Did it prevent confidential-data exposure, Injection, privilege violations, and dangerous side effects?
• Operational evaluation: Are latency, cost, retries, and availability within their thresholds?

7.2 Examine the Failures Hidden Behind the Average

Even with an average score of 95, release may be unacceptable if it includes any of the following.

• Once in every 100 attempts, it returns another customer’s information
• Infrequently, it confirms an order without approval
• It circumvents safety rules only in a particular language
• When a Tool fails, it reports an operation that was never performed as successful

A release gate must therefore include not only averages, but also conditions that must never occur even once.

8. Return Everything to a Single Control Loop

The mechanisms discussed so far operate as the following cycle.

flowchart LR
    A[Discover] --> B[Establish owner and principal]
    B --> C[Restrict paths and permissions]
    C --> D[Inspect input and output]
    D --> E[Collect execution evidence]
    E --> F[Evaluate and detect anomalies]
    F -->|Issue found| B
    F -->|Criteria met| G[Release next version]
    G --> A

The inventory is not created once and then considered complete. Re-evaluate whenever a new version, new Tool, new destination, new user, or new attack technique is introduced.

Where the foundational section leaves us

Discovery, identity, paths, permissions, content inspection, evidence, and evaluation now form a single cycle. The minimum mechanisms needed to address NovaSmart’s immediate problem are in place.

What follows is not an introduction to new products. Instead, it explores three difficult problems that arise when the same mechanisms operate in production over time. First, an Agent with a valid name badge may bypass a user’s weaker permissions. Second, multiple decision points must be connected without contradiction. Third, logs must be transformed into auditable evidence.

9. Incidents That Still Occur After Separating Name Badges: Preventing the “Confused Deputy”

The discussion becomes somewhat more advanced from this point, but the starting point is straightforward.

Suppose an employee asks NovaSmart’s Personalization Agent, “Show me this customer segment.” The Agent itself can analyze customers from every region, but the employee is authorized to view only their own region. If the Agent fails to verify the employee’s scope and searches solely under its own broader permissions, the employee may be able to use the Agent as a proxy to read customer information from another region.

The Agent is not malicious. A highly privileged principal acted on behalf of a less privileged requester without adequately validating that requester’s intent. This is the longstanding confused deputy problem expressed through natural language and Tool selection.

9.1 Separate “The Agent Has Permission” from “It May Use That Permission for This Request”

An authorization decision requires not only the Agent’s principal, but also the user, purpose, target, operation, and time.

Authorization = f(
  User,
  Agent Identity,
  Business purpose,
  Operation,
  Target resource,
  Data classification,
  Time,
  Approval status
)

This formula is not a product specification. It is a way of thinking that prevents omissions during design. Even for the same customer data, retrieving one record to answer an inquiry differs in purpose and risk from exporting every record for promotional analysis.

There is no need to solve the formula mathematically. It is enough to read it from left to right as “the person making the request,” “the Agent acting on their behalf,” “the purpose of the work,” “the intended operation,” “the target,” “the sensitivity,” “when,” and “whether it has been approved,” and to authorize the operation only when all of them are present.

9.2 Choose Among Three Execution Models

Delegating the user’s permissions is not always the answer. Overnight automated processing has no user operating it at that moment. Conversely, giving every Agent broad permissions of its own removes access controls (ACLs) that define each user’s viewing scope. Choose an execution model for each operation.

9.3 Do Not Treat Tool Descriptions as Authorization Boundaries

Writing “Only administrators should use this Tool” in its description helps guide model selection. It does not provide enforceable authorization. Prompt Injection, model updates, Tool conflicts, or implementation defects may still cause it to be selected.

Descriptions provide guidance, Gateway policy provides control along the communication path, and IAM provides control at the resource. High-risk operations should additionally have business rules verified by deterministic code.

10. One Authorization Is Not Enough: Connect the Decision Points

A single request passes through multiple decision points.

The following table can be read from top to bottom in the actual order of communication. It verifies the user at the entry point, checks egress from the Agent to the Tool, validates the Tool arguments, and finally blocks the operation through IAM and business rules closest to the data. Passing any one row is not sufficient; execution occurs only after all required rows have been passed.

The important thing is not to consolidate everything in one location. Instead, performing a final check close to the resource provides resilience against upstream bypasses and misconfiguration. This is defense in depth, in which the next layer stops an action even if one layer is breached.

10.1 Separate Allow and Deny Reasons for Users and Operators

Returning overly detailed denial reasons may reveal existing resource names or internal policy to an attacker. Conversely, “An error occurred” does not help a legitimate user correct the problem.

• For users: Safely indicate what they can change
• For operators: Record the decision point, rule version, principal, and target involved in the denial
• For auditors: Provide tamper resistance, retention, and access control

The same denial does not need to expose the same information to all three audiences.

10.2 Design an Emergency Stop

Before a serious issue occurs, decide at which of the following levels the system can be stopped.

• Stop only a specific Agent
• Stop only calls to a specific Tool
• Degrade write operations to read-only
• Isolate only a specific customer organization (Tenant) or region
• Stop all outbound communication

The more shared principals and shared Endpoints there are, the broader the shutdown scope becomes. Separating identities and paths is necessary not only for least privilege during normal operations, but also to reduce the blast radius during an incident.

11. Collecting Logs Is Not Enough: Transform Them into Evidence

A large collection of graphs on an operations dashboard does not necessarily answer audit questions. Evidence should be collected in a form that can support or refute a claim.

For example, a mere error message may be weak evidence for the claim, “The promotional Agent could not read the customer table.”

1. Which Agent Identity was tested?
2. Which policy version was in effect at that time?
3. Which resource and permission were requested?
4. For what reason did IAM deny the request?
5. Was the resource unreachable through another path or Tool?
6. Did authorized operations by the legitimate Agent continue to work?

If only the denial case is tested, a network failure or authentication failure may also appear to be a successful denial. This is why allowed and prohibited cases should be paired under the same conditions.

11.1 Protect the Evidence Itself

Logs may contain confidential information, user requests, Tool arguments, and portions of business data. The observability platform must not become a new path for information leakage.

• Classify data before collection and Mask it when necessary
• Store hashes, lengths, classifications, and reference IDs instead of bodies
• Separate viewing permissions for developers, operators, and auditors
• Distinguish retention periods from legal holds
• Audit exports and secondary use
• Provide clock synchronization and tamper detection

“Record everything” does not mean “be safe.” The objective is to retain the information required for reconstruction in a minimal and trustworthy form.

11.2 Divide SLOs into Two Types

Availability SLOs alone can overlook deterioration in governance. For example, the response success rate may be 99.9% even while shared principals and missing evidence are increasing.

Therefore, divide SLOs—the service-level objectives agreed upon with users—into service SLOs and assurance SLOs.

In the following table, read the left side as “the health of the service delivered to users” and the right side as “the health of the mechanisms used to explain its safety.” Fast responses with missing evidence are unacceptable, and perfect evidence while business operations remain continuously unavailable is also unacceptable.

Bring both types into the same release decisions and operational reviews.

12. Organizational Design That Keeps Governance Moving: Do Not Concentrate Responsibility in the Platform Team

Even if a shared Platform Team operates the agent inventory and Gateway, one team cannot determine promotional policies, the meaning of customer data, and acceptable errors. Centralize the technical platform while distributing business responsibility to the relevant business domains.

If the central team manually approves every Agent, it will eventually become a bottleneck. Conversely, leaving everything entirely to individual departments leads to inconsistent inventories, identities, and evidence.

A good Platform provides the following as a “paved road.”

• A template that requires Owner, purpose, and data classification during registration
• Identity issuance for each Agent
• Standard connectivity through the Gateway
• Policy templates such as read-only, approval-required, and executable
• Shared traces and audit retention
• Standard pre-release evaluation
• Automatic suspension when an asset expires, lacks an Owner, or has a critical failure

Business teams can move quickly along the paved road and undergo additional review only when exceptions are required.

12.1 Determine Risk Tiers by Actions, Not Agent Names

Classifications such as “an FAQ Agent is low risk” and “a Finance Agent is high risk” are too coarse. Even for the same Agent, summarizing public information and changing a customer account have different risk levels.

This enables control at the operation level without imposing unnecessarily strong restrictions on an entire Agent.

12.2 Track Policy Drift as an Operational Change

Even if no code changes, the Agent’s effective capabilities change when IAM roles, Gateway rules, Registry metadata, Model Armor templates, or destination ACLs change.

Configuration changes should therefore be treated like releases.

1. Save the difference before and after the change
2. Enumerate the affected Agents and actions
3. Re-run representative allowed and denied cases
4. Observe that propagation has completed
5. Make it possible to return to the previous version if a problem occurs

This is why recording only the Agent code version is insufficient to reproduce its actual behavior.

Review of the advanced considerations

Having the correct Identity is only the starting point. Authorization must include the user’s purpose, requests must pass through multiple decision points, allowed and prohibited cases must be tested as pairs, and the results must be preserved as evidence resistant to tampering. Furthermore, unless each department can make its own business decisions, the central Platform Team will create a queue of requests awaiting approval.

The next unresolved problem: Translating this approach into daily operations requires explicit commitments, metrics, and incident procedures—not an abstract promise to “make it safe.”

13. Commitments to Uphold in Production

Writing these as verifiable commitments rather than product names makes design reviews easier.

Metrics to Monitor

Here, p95 latency is the response time within which approximately 95 out of 100 requests complete. It is used to observe the slower user experiences that averages tend to conceal.

• Number of running but unregistered Agents
• Duration for which ownership remains unknown
• Number of shared principals
• Number of Endpoints capable of bypassing the authorized Gateway
• Number of communication patterns outside the inspection scope
• Percentage of important operations whose traces can be joined from beginning to end
• False-positive and false-negative rates
• Number of evaluation cases that should be denied but pass
• Time required for policy changes to converge on expected results

14. How to Use This in Incident Response

Let us retrace the problem discovered at NovaSmart as a production incident investigation. A report has been filed that “customer information may have been searched without authorization.”

1. Use the Audit Log to identify the target resource, operation, principal, and time
2. Trace the principal to the Agent Identity and Agent resource
3. Use the Registry to confirm the owner, version, Endpoint, and accessible Tools
4. Use the trace to reconstruct the request, Gateway decision, Agent, and Tool invocations
5. Confirm the delegated user and authorization context
6. Confirm the content-inspection decision and the version of the applied template
7. Add the same conditions to the evaluation data and run a regression test after remediation

If there is a shared principal, no common trace, or no Data Access Log configuration, the investigation will stop partway through. Governance design should be evaluated by whether it can answer questions during an incident, not by the appearance of dashboards during normal operations.

15. Where to Start with Adoption

Start by Finding What Exists

Reconcile the runtime platform, reachable Endpoints, Registry, and actual usage. Rather than attempting perfect classification from the outset, prioritize detecting unknown owners and unregistered assets.

Then Separate Principals

Move to an Identity for each Agent and reduce long-lived Credentials and shared principals. Pair tests confirming that authorized processing succeeds with tests confirming that privileged operations are denied.

Close the Paths

Make the Gateway a mandatory path and identify direct Endpoints, alternative protocols, and unknown destinations. Retain IAM as the final line of defense at the resource.

Measure the Inspection Scope

Instead of relying on configuration names such as Model Armor, verify coverage for every direction and format of actual traffic. Measure the impact on normal business operations at the same time.

Connect Evidence to Release Decisions

Do not stop at collecting logs. Connect evaluation failures, policy violations, and unregistered assets to release gates and remediation workflows.

16. Briefly Addressing Common Misconceptions

“It Is Safe Because It Is Listed in the Registry”

The Registry is an entry point for explaining ownership and capabilities. It does not prove that the execution principal, permissions, paths, inspection, and actual behavior are safe.

“Separating Service Accounts Makes It Auditable”

Separating principals is necessary. However, without connecting the user, owner, trace, target resource, and policy version, the business-level causal relationship remains incomplete.

“Gateway Replaces IAM”

Gateway primarily protects invocation paths, while IAM primarily protects resource operations. Neither closes the system by itself.

“Enabling Model Armor Makes It Safe”

Do not test merely for the presence of a configuration. Verify that required communications actually pass through the inspection point, expected violations are stopped, and normal processing remains intact.

“There Are No Logs, So Nothing Happened”

No conclusion can be drawn until the recording scope, retention period, viewing permissions, and search criteria have been checked.

“The Evaluation Average Is High, So We Can Release It”

Even rare but serious privilege violations or information leaks are hidden by averages. Maintain separate no-release conditions.

17. Practical Checklist

Inventory

• Running, registered, reachable, and actually used assets can be obtained separately
• Relationships among Agent, Endpoint, Tool, Skill, and Publisher can be traced
• Owner, purpose, data classification, and lifecycle are recorded
• Unregistered assets and retired assets that remain in place are detected continuously

Principals and Permissions

• Each Agent has a separate execution principal
• Long-lived keys and shared Credentials have been reduced
• Owner, Agent, and user are recorded distinctly
• Allowed and denied tests are maintained as pairs
• Read permissions and external-transmission capabilities are evaluated together

Paths and Content Inspection

• Paths that do not pass through the Gateway are known
• Inspection coverage is defined for each protocol, direction, and format
• Tool results and attachments have also been considered for inspection
• False positives, false negatives, and latency are measured

Evidence and Evaluation

• A common trace follows the request through the data operation
• Data Access Log configuration and retention have been verified
• Storage of message bodies has been minimized, and viewing permissions are controlled
• Tool paths, not only outcomes, are evaluated
• High-risk failures are separated from averages

Conclusion

The lesson of the Day 2 Platform Builders Track is not that we should “install every governance product” before increasing the number of agents.

First, know who is present. Next, give each one a separate name badge. Require them to use the authorized entrance, give them keys appropriate to each room, and establish checkpoints for dangerous material. Then ensure that you can explain afterward which request became which action.

Following this sequence turns governance from a wall that blocks development speed into a platform that clearly defines what can be delegated safely and enables agents to take on more substantial work.

Official Documentation

• Gemini Enterprise Agent Platform overview
• Agent Registry overview
• Register agents
• Agent Identity overview
• SPIFFE Overview
• IAM principals overview
• Authenticate using the Agent’s own Authority
• Agent Gateway overview
• IAM Deny policies
• Model Armor overview
• Model Armor and Agent Gateway integration
• Cloud Audit Logs overview
• Configure Data Access audit logs
• Agent tracing
• Evaluate agents