by Shahzad Ali

on March 16, 2026

AI agents are often discussed in abstract terms, which can make them feel experimental or hard to operationalize. In reality, many teams already run systems that behave like agents: automated runtimes that take actions on behalf of engineers based on intent and context.

This post walks through a production‑oriented use case for agents running on Google Cloud Platform (GCP), focused on secure, read‑only access to customer environments using just‑in‑time (JIT) permissions. All customer-specific names and identifiers have been anonymized.

The Problem We’re Solving

SRE teams frequently need temporary, scoped access to customer environments to:

Inspect logs and metrics
Validate configuration
Investigate incidents
Answer operational questions quickly

The challenge is balancing speed with safety:

Avoid long-lived credentials
Avoid standing privileges
Maintain strong auditability
Keep the workflow scalable across many customer projects

High-Level Architecture

The setup is intentionally simple and operationally friendly:

One GCP project per SRE (isolation boundary)
One VM per SRE project
One service account per VM (execution identity)
An AI agent runtime runs on the VM
The agent can be instructed to inspect other GCP projects (customer environments)
The agent uses Britive to request read-only JIT access to the target project

The key principle: the agent’s identity is the VM service account, and permissions are granted temporarily.

Simple Architecture Diagram

Mermaid (best for blogs/docs that render Mermaid)

flowchart LR
  subgraph SRE_Project[Per‑SRE GCP Project]
    VM["VM (per engineer)"]
    SA["(VM Service Account\nagent@user-project...)"]
    Agent["Local AI Agent\n(automation runtime)"]
    VM --> Agent
    VM --- SA
  end

  subgraph Britive[Brtv: JIT Access Broker]
    OIDC["OIDC Federation\n(trust GCP-issued JWT)"]
    API[Britive API / pybritive]
    Prof["Profile Catalog\n(RO per customer project)"]
    OIDC --> API
    Prof --> API
  end

  subgraph CustProj["Customer GCP Project (anonymized)"]
    IAM[IAM Policy / Roles]

    Logs[Logs / Metrics / Read APIs]
  end

  Agent -- 1) Get signed JWT from\nGCP metadata server --> OIDC
  Agent -- 2) Checkout RO Profile\n(via API/CLI) --> API
  API -- 3) Apply ephemeral RO roles\n(to VM service account) --> IAM
  SA -- 4) Read-only access --> Logs

How Just‑in‑Time Access Works in This Pattern

Think of Britive as a broker that controls when and how access is granted:

The agent determines which customer GCP project it needs to inspect.
The agent authenticates to Britive using a keyless, federated identity (OIDC).
The agent checks out a Britive Profile that corresponds to the target customer project.
Britive applies ephemeral, read-only permissions.
The agent uses those permissions to perform read-only inspection (logs/metrics/APIs).
When time expires or access is checked in, permissions are removed.

This aligns with the “zero standing privileges” posture described in Britive collateral and access broker overview materials.

Authentication Without Static Credentials (OIDC + GCP Identity)

A key requirement here is no static secrets on the VM.

A common approach is to use OIDC federation where the workload presents a signed identity token (JWT) and Britive validates it. Your internal GCP PoC prerequisite checklist explicitly frames using Workload Identity Federation (WIF) to enable “secure, keyless authentication,” and calls out creating a Workload Identity Pool and Provider (OIDC) in GCP as part of the setup. [Britive-GC…OC-Prereqs | Word]

Identity Mapping: Who Is “Calling” Britive?

In this use case, there are two identities that matter:

Human identity (the SRE) — who instructed the agent
Workload identity (the VM service account) — who actually executes actions

The requirement is clear: permissions must land on the VM service account, not the human’s corporate account.

Operationally, the cleanest mental model for this blog is:

The agent authenticates as a non-human identity (NHI).
Britive policy determines which profiles that identity can check out.
Access is granted to the service account principal that represents that agent runtime.

Britive positioning materials explicitly discuss supporting JIT and ephemeral authorization for non-human identities. [Britive -…ion – 2025 | PowerPoint], [2025_JAN_B…ew Shahzad | PowerPoint]

Profile Strategy (Scalable Design)

To keep configuration scalable:

One Britive Profile per customer GCP project (or per customer “environment” boundary)
Profiles are read-only and reusable by multiple agent identities
You avoid “profile explosion” (one per customer × per engineer), which becomes unmanageable at scale

This approach matches the idea that Profiles represent resource access shape, while policies/identities determine who can check them out.

Step-by-Step Reference Architecture (GCP + Britive + Agent Runtime)

Below is a reference architecture checklist you can include near the end of the blog. Where I reference specific steps, I anchor them to your existing PoC prerequisite guidance for GCP onboarding via WIF.
Anything beyond that is clearly labeled as “suggested implementation guidance.” [Britive-GC…OC-Prereqs | Word]