Agentic Governance: The Infrastructure Harness

"Most agent failures, examined honestly, are configuration failures." — Osmani, Saboo & Kartakis, The New SDLC with Vibe Coding (May 2026)

Agentic Governance is the governance layer of Infrastream's Agentic Development Platform — the guardrails half of an ADP's "paths, interfaces, and guardrails." It is not a standalone framework bolted on; it is the control plane that makes autonomy safe on top of the deterministic infrastructure foundation.

AI agents now clone repositories, plan multi-file changes, run in sandboxes, and submit pull requests autonomously. The industry has a rigorous framework for the coding harness — rule files, sandboxed execution, eval suites. What it lacks is an equally rigorous framework for the infrastructure harness: who governs what an agent can provision, and who it can act as?

Infrastream addresses both halves of that question — with the honest caveat that this layer is still maturing.

Current status & limitations

The agentic layer is early and under active development. Today: the agent runtime is ADK-only; agentic deployments should be re-tested per environment before production use and carry known limitations; governance is real but not yet complete — it covers the shipped Agent/AgentDeploymentConfig kinds, while MCP governance and broader policy controls remain in progress. The patterns below describe the intended model and current direction, not a finished, turnkey guarantee.

The Unique Value Proposition

Every AI-agent platform can generate configuration. Very few can answer what happens next: what the agent is allowed to touch, whose identity it acts under, and how fast your team can adopt the next thing Google ships. Infrastream is built around three pillars that answer exactly that — for every team, not just the ones with a dedicated ML platform group.

Pillar	What it means	How Infrastream delivers it
Governance	Every permission an agent has is declared, reviewed, and audited — never inherited or assumed.	Typed `Agent` manifests, CODEOWNERS-gated PRs, and a Spanner state ledger with full temporal history.
Managed Authentication	Agents get a scoped identity with automated IAM grants and token lifecycle — no team hand-rolls credential plumbing.	The engine provisions and refreshes agent identity (IAM bindings, audience-scoped ID tokens, IAP egress) automatically on deploy.
3-Legged Authorization	When an agent must act as a specific person — open a PR, touch a private repo — it gets that person's explicit, revocable consent. It never borrows a shared credential.	Built on Google's Agent Development Kit (ADK) credential-request flow: the agent requests a user token at the moment it's needed, scoped to that one action.

The payoff compounds: when Google ships something new for agents — as it did with Vertex AI Agent Engine and Agent Registry in 2026 — your team gets it as a manifest field, not a multi-week integration project. Pvotal's own product team did that integration first, internally, so customers don't have to.

The Spectrum: Vibe Coding to Agentic Engineering

The whitepaper's central argument: the harness determines agent quality, not the model. On Terminal Bench 2.0, one team moved an agent from outside the Top 30 to the Top 5 by changing only the harness — no model change.

Dimension	Vibe Coding	Structured AI-Assisted	Agentic Engineering
Intent specification	Casual natural language	Detailed prompts with examples	Formal specs, architecture docs, memory files
Verification	"Does it seem to work?"	Manual testing, spot-checking	Automated test suites, CI/CD gates, LM judges
Error handling	Copy-paste errors back to AI	Developer diagnoses root cause	Agents self-diagnose within defined bounds
Risk profile	High; acceptable for disposable code	Moderate; human judgment at checkpoints	Low; systematic verification at every stage

Source: Table 1, "The New SDLC with Vibe Coding," Osmani, Saboo & Kartakis (May 2026)

For infrastructure, the stakes are higher than for code. A misconfigured IAM binding can expose an organization; an agent impersonating the wrong identity can do worse. Infrastream is the infrastructure harness that makes agentic engineering safe for production — including who the agent is allowed to be.

Why Infrastructure Needs This

Traditional IaC (Terraform, Pulumi, CloudFormation) encodes capability without constraining intent: no typed schema, no dependency governance across projects, no historical audit trail, and — critically for agents — no distinction between "the agent's own permissions" and "permissions borrowed from a human."

AI amplifies this. An agent can generate syntactically valid Terraform that grants roles/owner, opens a firewall to 0.0.0.0/0, or calls a GitHub API using a shared bot token when the action should have required a specific person's consent. The whitepaper calls the gap between "generates working code" and "handles the edge cases correctly" the 80% problem. For infrastructure and identity, the missing 20% is catastrophic, not subtle.

The Infrastream Harness Model

Infrastream implements the whitepaper's harness anatomy for infrastructure and identity:

Harness Component (Whitepaper)	Infrastream Implementation
Instructions & Rule Files	Manifest schema + organizational hierarchy (`Organization → OU → Environment → Project`)
Sandboxes & Execution Environments	Per-project isolation, egress whitelisting, network boundaries
Guardrails / Hooks	Schema validation at PR time, CODEOWNERS on manifest directories
Identity & Credentials	Automated agent-identity IAM grants, ID token refresh, IAP egress — plus 3-legged consent for actions taken as a specific user
Observability	Spanner State Ledger with millisecond-granularity temporal reconstruction, RunEvents streaming

The whitepaper states: "When an agent does something wrong, the first instinct is to blame the model. More often, the failure traces back to a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise." Infrastream's guardrails aren't vague rules or ad-hoc credential sharing — they're typed manifests and managed identity, both reviewed through the same process as application code.

Agentic Manifest Kinds

Shipped today

Agent — declares an AI agent deployed to Vertex AI Agent Engine, with explicit access controls:

apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: compliance-auditor
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "SOC2 compliance auditor — reads infrastructure state, generates findings"
  target: AGENT_ENGINE
  project: platform-core
  buildDefinition: compliance-agentic-build   # BuildDefinition (type: AGENT) that packages this agent
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_PLATFORM_CORE_CONNECTION_STRING
      schema: platform-core
      name: main
      privileges: [SELECT]  # Read-only — principle of least privilege
    secrets:
      audit-api-key:
        envVar: AUDIT_API_KEY

Every permission is visible in the PR diff. Beyond what's declared here, the engine automatically provisions the agent's runtime identity — IAM grants and token refresh — without a separate manifest field. See Agent manifest reference for the full schema and Authentication below for what happens under the hood.

BuildDefinition(type: AGENT) is still maturing

buildDefinition must reference a BuildDefinition manifest with type: AGENT. That manifest's agent block requires registry, entryModule, packageName, and agentDirectory — but today only registry is actually consumed by the engine (to grant CI artifact-push IAM); the other three are schema-required yet not read by any consumer. type: AGENT also has no CI workflow builder yet, so automated build generation will fail. Plan to build and publish the agent wheel manually until this lands.

AgentDeploymentConfig — pins an Agent to a specific version per environment, following the same release-track discipline as applications. See the Agent Deployment Config reference for the schema and examples.

McpConfig — declares an MCP (Model Context Protocol) server deployed as a Cloud Run service, exposing tools to agents through the Agent Registry, under the same typed-manifest governance as Agent. MCP servers already ran in production before this kind shipped (e.g. Pvotal's own Code Graph MCP server via the standard Application manifest); McpConfig brings new deployments under governance. See MCP Config reference for the full schema.

Authentication, Managed by Default

This is the part most infrastructure-as-code tools never touch: who is the agent, and whose permission is it acting on?

Agent identity (2-legged)

Every agent deployed through Infrastream gets its own scoped identity — not a shared, over-privileged CI/CD service account. On deploy, the engine automatically:

Grants the specific IAM roles the agent's identity needs to reach its registered tools (e.g. agentregistry.viewer) and to call out through the platform's network boundary (iap.egressor) — scoped narrowly, not inherited wholesale.
Issues and proactively refreshes audience-scoped ID tokens, so a long-running agent session or a Reasoning Engine restart doesn't silently lose access.

None of this is a manifest field you write — it's automatic behavior the engine performs for every Agent resource, the same way it handles IAM for every other GCP resource type.

End-user authorization (3-legged)

Some actions shouldn't be taken as "the agent." Opening a pull request, commenting as a specific developer, or touching a private repository should be attributable to the person who asked for it — with their explicit, revocable consent, not a shared bot token.

Infrastream's agent runtime supports this via Google's Agent Development Kit (ADK) credential-request flow: when an agent reaches a tool call that requires a specific user's identity, it pauses and requests that user's consent at that exact moment, scoped to that one action. The agent never holds a standing credential on the user's behalf.

See a concrete example — an onboarding agent that opens GitHub PRs under the requesting developer's own identity — in Agent Use Cases: Delegated User Authorization.

Why this matters

Two-legged and three-legged authorization solve different problems. Managed identity keeps an agent's own permissions narrow and automatically maintained. 3-legged authorization is designed so an agent does not quietly act with more authority than the human in front of it intended. Infrastream implements both today (via ADK) — a combination few agent platforms offer.

Security: The Agentic Trust Boundary

Infrastream enforces trust boundaries through the manifest schema and managed identity — not documentation or tribal knowledge.

What agents cannot do, by design:

Create IAM bindings outside their declared project boundary
Modify egress rules (defined in the Project manifest, outside agent reach)
Deploy to production without release-track versioning
Access undeclared secrets or databases
Act as a specific end user without that user's explicit, per-action consent

Capability	Traditional IaC	Infrastream
Agent IAM scoping	Manual policy documents	Manifest `accessControl` with explicit privileges
Agent identity & token lifecycle	Hand-rolled per team, easy to get wrong	Automated IAM grants + proactive token refresh
End-user delegated actions	Shared bot credentials, unattributable	3-legged consent, scoped and revocable per action
Secret access	Environment variables, CI/CD injection	Declared in manifest, injected by engine
Deployment governance	CI/CD gates, branch protection	Git PR + schema validation + graph resolution
Temporal accountability	Current state only	Spanner State Ledger, millisecond-granularity history

Economics: Structure as a Cost Lever

"Vibe coding appears incredibly cost-effective. The CapEx is negligible. However, the economics hide a massive, compounding OpEx burden: token burn rate, maintenance tax, security remediation." "Agentic engineering flips this economic model. It requires a deliberate, upfront investment — but the marginal cost of shipping a feature drops dramatically."

Infrastream is that upfront investment, already made:

Context = Manifests. No token waste on unstructured Terraform dumps — manifests are the dense, high-signal context.
Guardrails = Schema. Agents can't produce invalid infrastructure or claim an identity they weren't granted.
Evals = State Ledger. Every provision and every credential grant is tracked and temporally reconstructible.
Adoption cost, paid once. Pvotal's own migration to Vertex AI Agent Engine and Agent Registry — new ADK bridges, eval frameworks, IAM automation — took real engineering effort. Every Infrastream customer gets the result of that work as a manifest field.

Three Durable Principles

The whitepaper's three durable principles map directly onto Infrastream:

Structure scales, vibes don't. Infrastream manifests are typed, versioned, and validated before execution — there is no "vibe provisioning," and no ambient credential sharing.
AI amplifies your engineering culture. Organizations with Infrastream don't have to hope their agents follow least-privilege and consent practices — the schema and the identity layer enforce it.
The human role is evolving, not diminishing. Humans design the org structure, set the security and consent boundaries, and review the manifests. The engine provisions. The agent acts — as itself, or as an authorized human, but never as anything undeclared.

Getting Started

Deploy your first agent — production-grade use cases, including the delegated-authorization pattern
Agent manifest reference — full specification of the Agent kind
MCP Config reference — full specification of the McpConfig kind
Read the architecture — the graph engine that powers it all

Generation is the easy part. Governance and identity are the hard part.

The bottleneck in AI-assisted infrastructure is no longer generating configuration — it's governing what agents can touch and controlling whose identity they act under. That is the problem Infrastream is built to solve; the agentic layer that does it is still maturing (ADK-only today, with limitations noted above).

The Unique Value Proposition​

The Spectrum: Vibe Coding to Agentic Engineering​

Why Infrastructure Needs This​

The Infrastream Harness Model​

Agentic Manifest Kinds​

Shipped today​

Authentication, Managed by Default​

Agent identity (2-legged)​

End-user authorization (3-legged)​

Security: The Agentic Trust Boundary​

Economics: Structure as a Cost Lever​

Three Durable Principles​

Getting Started​