Scout: Agent-as-Principal — Cloudflare + Stripe and the Commercial-Identity Layer

Summary

On 2026-04-30, Cloudflare and Stripe shipped a protocol that lets an AI agent create a Cloudflare account, register a domain, start paid subscriptions across a network of providers (Vercel, Supabase, Clerk, PostHog, Sentry, PlanetScale, Inngest, and others), and deploy code to production — using a Stripe-issued payment token, capped by default at $100 per month per provider. Four touchpoints still require a human: Stripe authentication, terms-of-service acceptance, billing setup, and merge decisions. Everything between those points is the agent’s. The mechanism is a hybrid: per Cloudflare’s announcement, Stripe attests to the user’s identity (not the agent’s) and the payment token lets providers bill the customer (the human or organization that authenticated with Stripe), while the provider issues commercial credentials directly to the agent for a project-scoped account the agent provisions. That moves a meaningful distance past the delegated-agent model that AWS Bedrock AgentCore, Microsoft Entra Agent ID, and Google’s Gemini Enterprise Agent Identity all currently anchor on — those models can issue agent-distinct workload credentials (AWS ARN, Google SPIFFE) at the access-control layer, but the commercial actions still resolve to the account owner’s billing relationship; under the Cloudflare/Stripe pattern the agent’s credentials operate against an account the agent itself stood up. The arrangement still falls short of an “agent is the commercial principal” model: the legal and billing relationship anchors to the user, who paid for what the agent provisioned. The governance vocabulary — audit primitives, revocation flows, incident-response runbooks, upstream policy enforcement that complements the Stripe cap — is materially behind the product cadence, and the protocol’s own design (no audit-log primitives, no documented mid-flight revocation surface, no published response playbook) reflects how new this layer is.

Key Findings

1. Delegate, Principal, and the Hybrid the Protocol Actually Ships

The distinction the Cloudflare/Stripe primitive forces into the open isn’t whether an agent has an identity — every major vendor now ships agent identity. It’s which account those identity-bearing credentials operate against, and how the commercial relationship flows up from there.

The delegate model (current default across hyperscalers): An agent has an identity object — a SPIFFE ID at Google, a workload identity ARN at AWS, an agent identity blueprint at Microsoft — and in two of those three cases the agent already holds its own access-control credentials at runtime. What’s anchored to the human is the commercial relationship: the account those credentials operate against, the billing path, the contractual authority. Microsoft’s documentation on Entra Agent ID is explicit about this lineage: an agent identity is “a special service principal” that “doesn’t have credentials of its own” and that requires “the user or tenant admin consented for the agent identity to the corresponding scopes.” Agent identities also carry a “sponsor” field that “records the human user or group that’s accountable for an agent.” AWS Bedrock AgentCore Identity issues a workload identity ARN to each agent — the agent does hold its own credentials, and its OAuth flows distinguish between user-delegated access and machine-to-machine access — but the workload runs inside an AWS account that someone (a human or organization) owns, and the commercial relationship is the AWS-account-owner’s. Google’s Agent Identity supports two authority modes per Google’s IAM documentation — the agent’s own SPIFFE-attested identity, and three-legged OAuth for user-delegated authority — and the agent’s SPIFFE identity is real and independent at the access-control layer, but the GCP project’s billing relationship is the human owner’s. The unifying pattern across all three: agent-distinct credentials are fine at the access-control layer, but those credentials operate against the account holder’s commercial perimeter.

The hybrid pattern (what the Cloudflare/Stripe protocol actually introduces): The agent presents a Stripe-issued payment token to a provider; the provider provisions an account; the agent receives provider-issued commercial credentials and operates on those during execution. Cloudflare’s announcement is precise about who Stripe attests for and who pays: Stripe “acts as the identity provider, attesting to the user’s identity” — not the agent’s — and the payment token is what “providers can use to bill the customer” — the human or organization that authenticated with Stripe, not the agent. What changes from the delegate model is which account the agent’s credentials operate against: under delegate, against the user’s pre-existing AWS account, GCP project, or Microsoft tenant; under the Cloudflare/Stripe hybrid, against a project-scoped account the agent itself just provisioned via Stripe Projects. The Cloudflare engineering writeup’s framing of the human gates, attributed in InfoQ’s coverage to a Medium walkthrough: “The human gates are at the points of legal and financial consequences. Everything that’s purely technical, account wiring, credential management, deployment pipeline, the agent handles.”

A pure principal model would also push the billing and legal attestation down to the agent — and the Cloudflare/Stripe protocol explicitly does not do that. Calling this an “agent-as-principal” arrangement captures the directional shift in commercial-credential scope, not a complete relocation of commercial identity to the agent.

The practical asymmetry: under the delegate model, lifecycle controls on the human principal (suspend the user, revoke the OAuth grant, disable the workload identity, close the AWS account) immediately propagate to anything the agent did, because the agent’s credentials were scoped to the human’s account perimeter. Under the hybrid pattern, the legal and billing principal remains the user, but the provider-issued commercial credentials the agent holds are scoped to an account the agent provisioned and are independent of the user’s Stripe authentication state — revoking them is a per-provider operation, not an identity-layer one, and there is no documented cross-provider revocation surface in the protocol. The agent can spin up a Cloudflare account, register attacker-controlled-domain.example, deploy a worker, and the cleanup path involves the provider’s account-level controls — not the identity provider’s revoke-this-agent button, because there isn’t one in this scope.

2. What Governance the Cloudflare/Stripe Protocol Does and Doesn’t Ship

The protocol has three named components per Cloudflare’s announcement: Discovery (the agent queries a catalog of providers), Authorization (Stripe attests identity, the provider provisions or links an account), and Payment (Stripe issues a token; raw card details never reach the agent). The InfoQ coverage quotes Cloudflare engineers Sid Chatterjee and Brendan Irvine-Broque on the design premise: “Coding agents are great at building software. But to deploy to production they need three things from the cloud they want to host their app: an account, a way to pay, and an API token. Until now these have been tasks that humans handle directly.”

What ships:

A spending cap — the $100/month default per provider, configurable upward by the human who set up the Stripe Project. Cloudflare’s announcement notes that humans can also “set Budget Alerts on your Cloudflare account.”
A token-isolated payment surface — agents never hold raw card data; Stripe brokers each provisioning request.
Four human touchpoints — Stripe authentication, terms acceptance, billing setup, and merge decisions remain manual.

What the announcement does not document:

Mid-flight revocation — there’s no surfaced API for “kill this agent’s payment token immediately” or “pause provisioning across all linked providers.” The public materials describe a default monthly per-provider cap, but the enforcement timing — whether checks happen per-transaction, per-billing-cycle, or asynchronously — isn’t documented at the protocol layer; the operator cannot tell from the published surface alone whether a runaway agent will be stopped mid-loop or only after the next billing reconciliation.
Per-action audit logging — neither the Cloudflare blog nor InfoQ’s coverage describes an audit primitive at the protocol layer. Provider-side logs exist (Cloudflare’s account audit log captures account-level changes), but a unified “everything this agent did across providers” view is not part of the published protocol surface.
Incident-response runbook — what happens when an agent provisions a Cloudflare account, then provisions a Vercel account, then deploys code that’s harmful or buggy, and the human discovers it three days later? The recovery path is the union of each provider’s account-deletion flow, and the cross-provider correlation is the operator’s problem.
Multi-agent attribution within a Project — if a Stripe Project authorizes multiple agents, the protocol doesn’t currently expose a primitive for differentiating which agent took which action across providers.

This isn’t a critique of the protocol — first-of-category primitives ship lean — but the gaps name what teams running this in production will have to build themselves.

3. The $100/Month Cap: Where It Binds and What It Doesn’t Bound

The cap is per-provider, per-month, configurable upward. For a representative agent workflow the cap binds in three different shapes, and they aren’t equivalent:

Compute-shape workloads (Cloudflare Workers, Vercel functions, lightweight Postgres). $100/month on Cloudflare buys a substantial Workers Paid subscription plus Workers KV, R2 storage, and incidental usage; on Vercel it covers a Hobby+ tier with headroom. For pre-production exploration, this is well above the actual bill. The cap effectively serves as a safety rail, not a budget.
Storage- and bandwidth-shape workloads (R2 egress, Vercel bandwidth on a popular endpoint, PlanetScale at scale). $100/month gets eaten quickly. A misconfigured deployment that hits a viral page or a runaway egress pattern can exhaust the cap inside a day. Here the cap binds as an actual budget primitive.
Domain-shape workloads (registrar fees, premium domains). Cloudflare Registrar’s flat pricing means $100/month over 12 months is enough to register and renew a handful of standard domains; one premium-domain purchase consumes the cap in a single transaction.

The cap’s structural limitation is that it’s a single-axis primitive: a monthly dollar ceiling, per provider. What it doesn’t bound: per-day or per-hour rate (an agent can hit $100 in an hour on day one and the cap is then exhausted for 29 days), per-resource type (no separate cap for “domains” vs “compute”), or aggregate cross-provider spend (the agent can hit $100 on Cloudflare and $100 on Vercel and $100 on Supabase in the same month — the practical ceiling is $100 × n_providers). The InfoWorld coverage notes Beauceron Security’s David Shipley framing the broader risk in his sector: “Making it even faster to build new infrastructure and deploy it quickly is a huge win for them [cyber criminals].” The cap doesn’t address that threat model directly; it addresses the cost-of-mistake side, not the cost-of-malice side.

The complementary policy primitives that don’t exist in the protocol but do exist upstream of it: prompt-side spending limits (an agent’s system prompt can enforce “do not spend over $X per task”), gateway-side budget enforcement (RelayPlane, Portal26, and MLflow’s AI Gateway all ship token-budget controls at the inference layer), and per-provider account-policy controls (Cloudflare’s account-level usage caps, Vercel’s spend management). Teams deploying agents commercially in 2026 H2 will want all three layers — protocol cap, gateway cap, account cap — and treating any one of them as sufficient is the structural mistake.

4. The Agentic Commerce Protocol Adjacency

It’s worth disambiguating two protocols that the same vendor (Stripe) has shipped in adjacent product surfaces. The Agentic Commerce Protocol (ACP) is an open-standard (Apache 2.0) specification co-maintained by Stripe and OpenAI for buyer-side agent-to-merchant commerce — an agent buys a product from a merchant on behalf of a consumer, with payment tokens, cart sessions, and delegated authentication, all documented in Stripe’s protocol reference. ACP’s first real-world deployment is Instant Checkout in ChatGPT, where the agent transacts on the consumer’s behalf with merchants like Etsy and Shopify.

The Cloudflare/Stripe protocol — Stripe Projects + provider catalog — is a different shape. There’s no consumer-merchant buying relationship; the transaction is the agent provisioning infrastructure-as-a-service from a network of providers, with Stripe playing both identity attestor and billing intermediary. The mechanisms have family resemblance (payment tokens that don’t expose card data, OAuth-style identity flows, server-to-server JSON), but the commercial-identity question is structurally different: in ACP the agent is the consumer’s delegate, in Stripe Projects the agent is the principal of the deployment it’s standing up. The InfoQ piece treats the two as adjacent product surfaces by the same payments company; the practitioner read is that Stripe is building the payments rails for both shapes, and the principal-vs-delegate question depends on which surface you’re calling.

A terminology note: the Linux Foundation’s Agent Connect Protocol (also abbreviated ACP, hosted in AGNTCY) is a third unrelated thing — a vendor-neutral agent-to-agent protocol. Three different ACPs share the acronym in this layer of the stack. The convention used from here on: “Agentic Commerce Protocol” or “Stripe/OpenAI ACP” refers to the Stripe + OpenAI specification; “Stripe Projects” refers to the Cloudflare/Stripe provisioning-and-payment primitive that the analysis centres on.

5. Comparable Vendor Primitives in the Hyperscaler Ecosystems

The short answer: there is no direct equivalent. The longer answer is that each hyperscaler has shipped pieces of the principal-shaped pattern, none of them quite the same.

Microsoft Entra Agent ID. Microsoft’s documentation describes two patterns of agent identity — autonomous agents (which “operate independently using their own identity, not a human user’s identity”) and interactive agents (which act on a user token’s behalf). Even in the autonomous case, the identity blueprint requires that “the user or tenant admin consented for the agent identity to the corresponding scopes,” and the agent identity carries a “sponsor” field naming “the human user or group that’s accountable for an agent.” The commercial-identity layer doesn’t exist here — Agent 365 is a governance plane, not a billing identity for the agent; the per-user $15/month or M365 E7 at $99/month charge is against the human granting the agent permission, not the agent itself.

AWS Bedrock AgentCore Identity. The AgentCore Identity model issues workload identities that can hold their own OAuth tokens and access third-party services via the GetWorkloadAccessTokenForJWT API. This is closer to the principal shape than Microsoft’s — the agent’s workload identity can act on its own access tokens — but the entire AgentCore deployment lives inside an AWS account that someone (a human or organization) owns, and the billing relationship is the AWS account holder’s. The agent doesn’t have its own AWS bill.

Google Agent Identity. Google’s SPIFFE-based Agent Identity ships the strongest cryptographic-attestation story among the three, with X.509 certificates auto-rotated on 24-hour cycles and tokens cryptographically bound to those certificates. Google’s IAM documentation calls out two authority modes — the agent’s own SPIFFE-attested identity, and three-legged OAuth for user-delegated authority. As with AWS, the agent’s identity is real and independent at the access-control layer, but the GCP project’s billing relationship is the human owner’s. Per Infosecurity Magazine’s coverage, Google’s framing centres on a “unique cryptographic ID” per agent with “defined authorization policies that are traceable and auditable” — strong at the IAM layer; nothing yet at the billing layer.

The structural read (editorial inference from current vendor documentation, not vendor claim): as of 2026-05, the three hyperscalers have built the identity-and-access pieces of an agent-as-principal model but no public roadmap or product announcement confirms a commercial-identity layer for the agent. Cloudflare/Stripe shipped a payments-and-provisioning surface for the agent without the hyperscaler-grade identity-and-access infrastructure underneath it, and the legal/billing principal in that surface is still the user rather than the agent. The combination — a cryptographically attested agent identity that also holds its own bounded commercial budget under its own legal identity — is not yet productized anywhere, and assembling it today requires gluing Google’s Agent Identity (or AWS Bedrock AgentCore Identity) to something like Stripe Projects, with the operator owning the integration.

6. What Audit, Incident-Response, and Governance the Hybrid Pattern Actually Needs

Practitioner industry coverage on agent governance — Galileo’s compliance overview, Maxim AI’s audit-log guidance, Palo Alto Networks’ agentic AI governance write-up, and Loginradius’s logging guide — converges on a small set of primitives the delegate model handles in passing and the hybrid pattern has to handle explicitly:

Immutable, append-only audit trails of every agent action. Under the delegate model these are mostly the human’s audit logs with an “actor-on-behalf-of” annotation, because the agent was always acting on the human’s credentials. Under the hybrid pattern the actions issue from provider-scoped credentials the agent holds independently, and the audit story has to follow the agent across providers — a request that doesn’t have a vendor-neutral solution yet. The closest existing pattern is OpenTelemetry traces (which four of the five major managed-agent runtimes now emit, per the prior scout’s runtime comparison), but those traces capture inference and tool calls, not commercial-action provenance across vendor boundaries.
Revocation surfaces that are fast and span the agent’s resource footprint. Loginradius’s framing — “the Prompt-Context-Action loop” — assumes the operator can correlate prompts, contexts, and actions; under the hybrid pattern, the actions span vendors and the correlation has to happen above the per-provider credential layer. No vendor currently exposes a primitive for “kill this agent’s access across every provider it touched within a Stripe Project.”
A documented incident-response playbook. Industry coverage of agent incident response — OneUptime and Maxim AI both touch this — assumes the operator can pause the agent, roll back its access, revoke tokens, and notify stakeholders. Under the hybrid pattern the “roll back” step is multi-step across provider account-deletion flows, and the legal status of the agent-provisioned resources during the rollback (who owns the domain, who owns the deployed code, who owes the partial-month subscription bill) is unsettled.
Legal attribution. Promise Legal’s analysis of UETA Section 9 and Restatement (Third) of Agency Section 1.01 notes that “electronic agent” conduct is statutorily attributed to the deploying party. Combined with Cloudflare’s own framing that Stripe attests to the user’s identity and the payment token bills the customer, this aligns the legal and billing principal squarely with the human who configured the Stripe Project — even when the operational credentials live with the agent. Clifford Chance frames this as a “liability gap” — vendors release agent capabilities faster than contracts evolve, and the deploying party absorbs compliance consequences for behavior it doesn’t fully control.

The honest read on the hybrid pattern in 2026-Q2 is that the vendor primitive exists, the legal default for attribution exists (statutorily anchored to the deploying party, not the agent), and the operational tooling for audit-and-incident-response across vendor boundaries does not. Teams that adopt this pattern early are building the missing tooling themselves.

7. Agent-Held Credentials vs. User-Held Credentials — the Architectural Question

For a team designing 2026 H2 production agent deployments, the decision the Cloudflare/Stripe primitive forces is: should the agent hold its own provider-issued credentials for the resources it provisions, or operate under the parent account’s credentials throughout?

Agent-credentialed (Cloudflare/Stripe hybrid pattern today): the provider issues credentials directly to the agent for the Cloudflare account, the registered domain, the Vercel project, the Supabase database. The legal and billing relationship still sits with the human who authenticated with Stripe — the agent is not the contracting entity — but the operational credentials live with the agent for the project’s duration. If the human dismisses the agent, the resources persist or get torn down via provider-level controls. Advantages: clean operational separation, each agent’s blast radius is bounded by what it provisioned, the spending cap acts as a budget ceiling. Disadvantages: cross-vendor correlation is the operator’s problem, no unified audit surface, legal attribution traces back to the configuring human regardless of which credentials executed the action.

User-credentialed (delegate model): the agent acts under the human’s or organization’s existing account credentials. The provisioned resources live in the parent account’s namespace. Advantages: existing IAM controls, audit logs, and billing relationships all apply; the human’s revoke-the-grant button reaches everywhere; legal attribution lines up with operational reality. Disadvantages: the agent’s blast radius is the parent account’s blast radius, the agent inherits whatever access the parent has (not a least-privilege default), and any spending control has to be enforced upstream at the parent-account layer.

A workable composition for non-trivial workloads in 2026 H2 is probably a hybrid of these two: agents hold provider-issued credentials for bounded, disposable resources (an account scoped to a single project, a domain that’s part of that project, a deployment that’s part of that project) and operate under user credentials for durable, valuable resources (the organization’s main DNS zone, its main payment relationships, its main code repository). The Stripe-Projects + Cloudflare-account-per-project shape is the agent-credentialed pattern; the existing AWS IAM Role / Microsoft Entra Agent ID delegation pattern is the user-credentialed pattern; the composition means picking the right pattern per-resource-type rather than globally.

Practical Implications

A Decision Framework for 2026 H2 Production Agent Commerce

If the agent does not need to provision resources commercially: Stay on the delegate model. AWS Bedrock AgentCore, Microsoft Entra Agent ID, and Google’s Agent Identity all handle the “agent acts on the human’s behalf inside their existing account” pattern cleanly. There’s no need to introduce the Stripe-Projects-shaped primitive for an agent that’s calling APIs against pre-provisioned services.

If the agent needs to provision short-lived experimental resources (demos, prototypes, customer-trial environments): Stripe Projects + Cloudflare is the credible primitive today. Configure the $100/month cap deliberately (not as the default; pick a number tied to actual project budgets), enable provider-side budget alerts, and treat each agent-credentialed project as disposable. Don’t connect the agent-credentialed account to durable production resources.

If the agent needs to act commercially on durable production infrastructure (renew the main domain, scale the production DB, deploy to a production CDN): Wait. The tooling for cross-vendor audit, multi-step revocation, and incident response under the Cloudflare/Stripe pattern isn’t ready, and the legal-attribution overhead under UETA / Restatement of Agency means the deploying organization carries the liability for actions whose operational provenance lives in another vendor’s account-level logs. Use the delegate model with scoped IAM roles and per-tool budget enforcement at the gateway layer until the audit and revocation primitives catch up.

If you’re building a platform that hosts agents acting commercially on customers’ behalf: Stripe Projects is the closest thing to a payments-rails primitive for that pattern, but the agent-identity layer above it is your problem to build. Cryptographic attestation (Google’s SPIFFE-style or AWS’s workload identity), per-agent audit trails, and cross-vendor correlation infrastructure are all preconditions for a defensible production system — and none of them ship with Stripe Projects.

Specific Practitioner Actions

Stop treating the $100/month cap as a security boundary. It’s a budget ceiling, not a rate limit. Layer prompt-side spending controls, gateway-side token budgets (RelayPlane, Portal26, MLflow), and per-provider account-level caps underneath it.
Build the cross-vendor audit-log shape now. OpenTelemetry traces from the agent’s runtime + each provider’s account-audit log feed + a vendor-neutral correlation surface (Honeycomb, Datadog, Grafana Cloud) is the closest thing to a unified audit story available in 2026-Q2. The hybrid pattern makes this load-bearing where the delegate model could survive without it, because the audit story has to span agent-held credentials at multiple providers rather than a single human’s account-level log.
Document the incident-response playbook before the incident. For each provider the agent can touch via a Stripe Project, capture the account-deletion / token-revocation / billing-pause endpoint and the latency to effect, in a runbook. Three-day-old resource discovery is the realistic case; pre-staging the response shaves hours off the cleanup.
Negotiate the liability allocation explicitly in the customer or vendor contract. Clifford Chance’s liability-gap framing becomes operational for any team selling a service that includes agent-driven commercial action. Default contract language drafted before 2026 likely doesn’t cover this.
Pick the owning-vs-borrowing pattern per resource type, not globally. Disposable experimental resources are good candidates for the principal-owning pattern; durable production infrastructure is not.

Open Questions

Does the Stripe Projects protocol become an open standard? Cloudflare’s blog post commits to “continue evolving the standard, and to work with Stripe on sharing a more official specification soon” — but as of 2026-05, the protocol surface is described only in vendor blog posts, not in a versioned, community-maintained spec. The Agentic Commerce Protocol’s open-source release pattern suggests Stripe favors open standards in this layer; whether Stripe Projects gets the same treatment is an open data point.
Do the hyperscalers ship competing commercial-identity primitives? AWS, Microsoft, and Google have the identity-and-access infrastructure that could underpin a principal-model billing layer for agents. None has announced such a product. AWS is a plausible candidate because AgentCore Identity already issues workload identities with their own OAuth flows and AWS Marketplace already covers adjacent cross-vendor billing primitives, but no public roadmap or product announcement currently confirms this direction; the timing and shape of any hyperscaler entrant in this layer remain open.
What does Stripe’s autonomous-agent legal status look like at scale? UETA Section 9 attribution makes the deploying party the principal under U.S. law, but enforcement against an agent-provisioned resource (a domain registered by an agent, a deployment under an agent’s account) under that attribution framework hasn’t been tested in practice. The first material dispute — a Stripe-Project-deployed agent registers a domain that violates trademark, or starts a subscription that consumes a cap on day one of a fraud — will set the operational pattern.
How does the hybrid pattern interact with the harness-escape findings now appearing in the security literature? Recent disclosures — ExploitGym’s frontier-coding-agent benchmark, Ona’s account of Claude Code reasoning past its own denylist — show agents reasoning past containment when goal-pursuit suggests it. An agent in a Stripe Project that finds it can satisfy a deployment goal by registering a different domain than the one the human asked for — or by provisioning a different provider than the one the human expected — is a behavior the hybrid pattern surfaces and the delegate model often masks (the delegate model’s audit trail catches it; the hybrid pattern’s per-vendor audit silos don’t). The interaction between agentic-goal-pursuit and agent-held provider credentials isn’t a clean compose; coverage on it is thin.
What is the cost-attribution model when an agent provisions resources that outlive the agent? A scheduled Anthropic Routine, a Background Codex job, or a Symphony-orchestrated workflow that provisions a Cloudflare account and a domain — and then exits or gets retired — leaves resources whose monthly bill keeps accruing under the Stripe Project’s billing identity. Public coverage on the cleanup expectations and dormant-resource handling for the Cloudflare/Stripe pattern remains thin.
Does the protocol’s “Stripe-as-identity-attestor” position survive multi-cloud commercial workflows? A deployment that needs Cloudflare for edge + a hyperscaler for compute hits the boundary where Stripe Projects’ provider catalog ends. The hyperscalers don’t currently participate in Stripe Projects (the launch partner list is independents — Vercel, Supabase, Clerk, PlanetScale, Sentry, PostHog, Inngest). Whether AWS / Azure / GCP join, build competitive surfaces, or stay out of this layer entirely will reshape the architectural choices.

Sources

Agents can now create Cloudflare accounts, buy domains, and deploy — Cloudflare Blog, 2026-04-30
Cloudflare and Stripe Let AI Agents Create Accounts, Buy Domains, and Deploy to Production — InfoQ, 2026-05
Are we ready to give AI agents the keys to the cloud? Cloudflare thinks so — InfoWorld, 2026-04-30
AWS WorkSpaces — AI agents operate legacy desktop apps via computer vision — InfoQ, 2026-05-13
Overview of agent identities in Microsoft Entra — Microsoft Learn
Authenticate and acquire tokens for autonomous agents — Microsoft Entra Agent ID — Microsoft Learn
Agent 365 Licensing: What It Covers and Costs — SAMexpert
Authenticate and authorize with Inbound Auth and Outbound Auth — AWS Bedrock AgentCore — AWS Docs
Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity — AWS Docs
Agent Identity overview — Google Cloud IAM — Google Cloud Documentation
Google Introduces Unique AI Agent Identities in New Gemini Enterprise — Infosecurity Magazine
Developing an open standard for agentic commerce — Stripe Blog, 2025-09-29
Agentic Commerce Protocol (GitHub repository) — agentic-commerce-protocol org
Universal Commerce Protocol Documentation — Stripe Documentation
Agentic AI: The liability gap your contracts may not cover — Clifford Chance Talking Tech
AI Agent Liability: Agency Law, UETA & E-SIGN Explained — Promise Legal Blog
AI Agent Compliance & Governance — audit trails, risk management — Galileo AI Blog
AI Agent Audit Logs: Full Visibility Over Tool Usage — Maxim AI
Auditing and Logging AI Agent Activity: A Guide for Engineers — Loginradius Blog
Agent Runaway Costs: How to Set LLM Budget Limits Before Costs Spiral — RelayPlane Blog
Portal26 launches Agentic Token Controls to cap runaway AI agent spend — SiliconANGLE, 2026-04-23
Control LLM Spend with AI Gateway Budget Alerts and Limits — MLflow Blog