Dora NodaOn July 21, 2026, the CNCF blog published a thesis about the future of platform engineering: stop treating AI agents as a bolted-on integration and start treating them as first-class consumers of the platform, alongside humans. Applications, resources, and AI agents become the three things a platform manages; humans and agents become the two kinds of tenants it serves.
It is a good thesis. It is also, in its original form, a vendor-authored pitch for a Sandbox-stage project. So this post does the unglamorous work the thesis invites: translate "agent as a first-class tenant" into five concrete requirements on a deploy API, check each one against what a self-hosted, Render-compatible platform actually ships today, and mark what is shippable now versus aspirational. Here is the whole article in one table; the rest substantiates every row.
| # | Requirement | What it concretely means for a deploy API | Bex today (public surface) | Verdict |
|---|---|---|---|---|
| 1 | Distinct identity per agent | Agents authenticate as themselves, not as a shared human API key | MCP over OAuth 2.1 with consent; API keys + OpenFGA roles | Ship today |
| 2 | Scoped permissions | Least-privilege grants per agent, per environment — deploy to staging, never production | Workspace roles via OpenFGA; per-agent scope narrowing still maturing | Partial |
| 3 | Machine-readable state | Every deploy/rollback/log action readable and writable as structured data, not dashboard HTML | REST + GraphQL + MCP + CLI on one core; "no dashboard-only actions" | Ship today |
| 4 | Audit trails by default | Every agent action attributed to the run that triggered it, append-only | Audit logs shipped; run-attributed agent spans depend on still-experimental OTel GenAI conventions | Partial |
| 5 | Resources + relationships as first-class objects | Databases, secrets, models, and their dependency graph modeled with lifecycle and governance — plus "context" agents can reason over | Services, Postgres, Key Value, domains modeled as resources; cross-resource relationship graph and "context capability" | Aspirational |
That table is the honest version of the CNCF pitch: two rows you can ship this quarter, two rows that are half-built across the whole industry, and one row that is still mostly vocabulary.
What the CNCF post actually argues
The post is "Platform engineering for the agentic enterprise: Managing applications, resources, and AI agents", by Lakmal Warusawithana of WSO2, and its demonstration vehicle is OpenChoreo, a CNCF Sandbox project that grew out of WSO2's Choreo platform. Steelmanned, the argument has three parts.
First, what the platform manages expands. Applications remain the primary way organizations deliver value, but resources — databases, messaging, object storage, AI models, APIs, identity providers, secrets, clusters, SaaS services, execution environments — stop being "infrastructure details" and become managed objects with their own lifecycle, ownership, governance, and operational history. AI agents join them as a third first-class entity.
Second, who the platform serves expands. Developers, platform engineers, and SREs keep their portals, CLIs, APIs, and GitOps workflows. Agents get the same platform through MCP servers. Different interfaces, same underlying understanding of applications, resources, relationships, and operational state — and, crucially, the same permissions and guardrails regardless of which interface an action arrives through.
Third, context becomes a platform capability. Once the platform understands applications, resources, agents, and how they depend on one another, it can expose that understanding to each consumer in its native interface: dashboards for humans, MCP for agents.
A companion CNCF post from two weeks earlier, "Evolving platform engineering for AI-native workloads" (July 6, 2026), lands in the same place from the survey-data direction: AI systems are becoming consumers of platform services and need governance, access controls, and guardrails "similar to those applied to human" users. Two posts, one consensus: the agent is a tenant now. The question is what tenancy costs to build.
1. Distinct identity: the agent is not your API key
The CNCF post's sharpest operational sentence is that the platform "can no longer assume that every interaction originates from a human" and must give "each actor a distinct identity, scoped permissions, and a clear audit trail." Start here because everything else depends on it: without identity, there is no scoping and no audit worth trusting.
The concrete API meaning is unglamorous. An agent authenticates as itself — a machine credential with its own lifecycle — never as a copy-paste of a human's personal API key. The industry has already converged on the mechanism: the MCP authorization specification mandates OAuth 2.1 for HTTP transports, with the client_credentials grant as the correct flow for machine-to-machine callers that have no human in the loop to click through an authorization page.
Interactive agents use the authorization-code flow with PKCE; background operators use client credentials. Either way the token is short-lived, refreshable, and revocable server-side — every property a static API key lacks, and exactly the properties agent workflows need most, since agents store, copy, and log credentials far more promiscuously than humans do.
Against that bar, bex's public surface reads as ship-today: the Teams surface lists OAuth 2.1 alongside API keys and OpenFGA-backed roles, and the agent surface runs remote and stdio MCP behind OAuth consent.
The remaining gap is the one the whole ecosystem shares — host identity. As a July 2026 analysis of the MCP spec's blind spots put it after MCP Dev Summit Mumbai 2026, the spec covers the client-to-server edge (discovery, registration, scoped tokens) but leaves the host — the process running multiple agent clients — as an identity blind spot. Your deploy API can know which token called it while still not knowing which supervisor process holds that token. Nobody has solved that yet; treat any vendor claiming full agent-identity provenance with skepticism.
2. Scoped permissions: least privilege per agent, per environment
Identity answers who called. Scoping answers what that caller may touch — and for agents the answer needs to be narrow, because agents act at machine speed with machine literal-mindedness.
"Deploy to staging, read logs everywhere, never touch production secrets" is the canonical grant, and the deploy API has to express it natively: per-workspace, per-environment, per-resource-type permissions evaluated on every call, not a single admin token with a prayer.
This is where "same guardrails regardless of interface" gets tested. It is easy to enforce scopes on the REST API and forget the MCP tool surface, or vice versa — and an agent will find whichever door was left open, not out of malice but out of path-of-least-resistance tool selection.
OpenChoreo's stated model is the right one: external agents hitting its two MCP servers (control plane and observability) get exactly the permissions and guardrails a developer user gets, because both interfaces resolve against the same policy core.
Bex's architecture makes the same bet structurally: dashboard, REST, GraphQL, MCP, CLI, and Kubernetes resources all operate one core, with "no dashboard-only deployment actions" — which cuts both ways, since it also means no interface accidentally grants what the core would deny. Workspace roles backed by OpenFGA supply the policy engine.
Verdict: partial, honestly. The policy core exists; the per-agent, per-environment scope-narrowing UX — minting a staging-only deploy token for one agent run from chat, expiring it when the run ends — is where every platform in this category, bex included, is still building. If you take one operational rule from this section: any agent credential that outlives the run it was minted for is a scope bug.
3. Machine-readable state: the API is the agent interface
An agent that operates your platform by scraping the dashboard is not a first-class tenant; it is a screen-scraper with a token. First-class means every state transition the dashboard can show — deploy status, build logs, metrics, environment diffs, rollback targets — is available as structured data over documented endpoints, and every mutation the dashboard button performs is callable as a tool with the same semantics.
This row is the least controversial and the most load-bearing, because rows 1, 2, and 4 all assume it. Scoped credentials are pointless if the agent must fall back to an admin's browser session to read the one field the API doesn't expose. Audit trails are fiction if half of all changes happen through clicks no API records.
It is also the row where a Render-compatible API is genuinely an advantage rather than just compatibility theater. Render's API shapes for services, deploys, environment variables, and custom domains are stable, documented, and already understood by half the agent tooling in the wild — an agent that learned to manage Render can manage anything speaking the same shapes.
Bex's stated contract is exactly this: Render-style Blueprints (bex.yml in the render.yaml shape) compiled into App resources by the operator, with the same core served through REST, GraphQL, MCP (/mcp plus stdio), CLI, and Kubernetes resources. An agent performing a deployment through the MCP deploy tool — repo plus manifest in one call — is exercising the same core as the dashboard form.
Verdict: ship today, with one caveat that applies to the whole post — bex labels itself active development, not production-ready, and points to its evidence-backed parity ledger as the source of truth per capability. Check the ledger, not the marketing row.
4. Audit trails: attribute every action to the run that caused it
"Scoped permissions and a clear audit trail" is the second half of the CNCF post's identity sentence, and it is the harder half. Knowing which agent token triggered a deploy is table stakes. Knowing which run, pursuing which goal, invoking which tools in which order, spending how many tokens — that is what makes agent operations auditable rather than merely logged.
The deploy-platform half of this is shippable now and mostly boring: append-only deploy records (who/what/when/previous revision), immutable build logs, rollback entries that reference the deploy they undo. Bex ships audit logs and deploy history with cancel and rollback on its operations surface today.
The agent-decision half is where the industry is still scaffolding. The natural standard is OpenTelemetry's GenAI semantic conventions — span names like invoke_agent and execute_tool, token-usage and cost attributes, conversation IDs that tie a deploy back to the run that decided it. As of mid-2026, that standard is explicitly unfinished: every GenAI convention is still Development status, nothing is Stable, and the MCP-specific conventions are being actively realigned with the July 2026 protocol revision that removed the stateful handshake.
Building run-attributed audit on conventions that still move under your feet means versioning your telemetry like an API — or waiting. Either is defensible; pretending the standard is settled is not.
Verdict: partial. Ship the deploy-record half now; treat per-tool-call agent spans as a forward-compatible extension, and emit them following the GenAI conventions so today's logs become tomorrow's compliant traces.
5. Resources, relationships, and "context": the genuinely aspirational row
The CNCF post's most ambitious claim is that resources become first-class objects with relationships — the platform understands how applications, databases, secrets, models, and agents depend on one another, how changes propagate, and exposes that understanding as "context" each consumer can reason over.
Split this row in two, because the halves have different maturities. Modeled resources with lifecycles — a Postgres instance you can provision, back up, fork, and delete through the same API as the app that consumes it — are shippable and, frankly, table stakes for anything calling itself a platform.
Bex models web and private services, workers, cron jobs, static sites, managed Postgres, and Key Value stores as resources with their own operations; OpenChoreo does the same for its resource set. No controversy here.
The relationship graph plus "context as a first-class capability" is the aspirational part — the one place the post reads as vendor narrative rather than engineering plan. A dependency graph that correctly answers "which agents, apps, and secrets break if I rotate this credential" across every resource type, kept fresh by reconciliation rather than documentation discipline, is a hard distributed-systems problem that neither OpenChoreo (Sandbox tier, pre-1.0 ecosystem) nor anyone else in this category has demonstrated at production scale.
And "context" in the post does real rhetorical work while specifying almost nothing: no schema, no freshness guarantees, no conflict semantics when two agents reason over stale context differently. Until those exist, "context-aware platform" is a direction, not a feature. File this row under roadmap — and be wary of any platform, bex included, that presents its resource catalog as though the catalog were the graph.
The shippable slice, in build order
If you run a self-hosted deploy platform and want agents as tenants without waiting for the industry to finish its homework, the scorecard above implies a build order. Each step closes a gap from the previous section.
- Machine identity before anything else. Stand up OAuth 2.1 client credentials for agents on your MCP surface, keep human API keys human, and expire agent tokens with the run. This unblocks rows 2 and 4; nothing else can be trusted without it.
- One policy core, every interface. Resolve dashboard, REST, GraphQL, MCP, and CLI actions against the same authorization check — OpenFGA-style relationship tuples if you have them, workspace roles at minimum. Then add the per-agent scope-narrowing UX: staging-only tokens minted per run.
- Append-only deploy records with run attribution. Ship who/what/when/previous-revision on every deploy and rollback now; add OTel GenAI-convention spans (
invoke_agent,execute_tool, token usage) as a versioned extension so today's audit log grows into tomorrow's agent trace. - Model resources before modeling relationships. Get every resource type lifecycle-complete through the API first. Only then attempt the dependency graph — and expose it read-only to agents before any agent is allowed to act on it.
Notably, that is close to the order bex appears to be building in — shared core and machine-readable state first, OAuth-gated MCP and audit logs alongside, fine-grained agent scoping and the relationship graph still ahead.
Which is either validation of the sequence or evidence that every team reading the same constraints converges on the same roadmap. Both can be true.
The CNCF post ends where platform pitches always end: platforms that manage the whole estate — apps, resources, agents — for the whole tenant set — humans and agents — become the foundation of the "agentic enterprise."
Strip the enterprise framing and the claim survives contact with a much smaller reality: a self-hosted PaaS on machines you own needs exactly the same five rows, just with fewer zeroes. Agents are tenants now. Give them credentials, scopes, structured state, and audit trails — and save the context graph for after the audit log works.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and MCP surface agents can operate as first-class tenants. Star the repo on GitHub or deploy your first app today.
