Tag: AI development

On October 8, 2026, Google Cloud introduced the Gemini agent, a general-purpose agent for work, at its Gemini at Work event. The announcement, published as a post by Google Cloud CEO Thomas Kurian, makes a specific pitch: an agent with its own account, its own audit trail and a budget cap that pauses it. For anyone responsible for AI governance, that is a notable shift, because controls that used to be added afterward are now described as part of the product.

This is a vendor announcement. Google’s claims have not been independently tested, and the post gives no general availability date, eligibility rules or agent pricing. This piece sets out what was announced, what is not established, and the question it raises: the features are Google’s, but who owns the policy behind them? It follows our earlier look at CrowdStrike’s shadow AI agent product and is written for teams doing AI agent development or generative AI development, and for those adopting agents from vendors.

What Google announced

According to the Google Cloud post, the Gemini agent plans tasks, uses tools, connects to a company’s business systems and returns finished work in the documents and inboxes people already use. The governance claims fall into four groups.

Identity. Google says coworker agents have dedicated identities, including their own email addresses on a company domain, and see only the context a person or team gives them. In Workspace, an agent gets its own account with an email address, a calendar, a Drive and a place in the company directory. Google also says each identity is cryptographically attested and limited to least-privilege permissions.

Audit trail. Google says every action the agent takes is written to an audit trail and “attributed to the agent rather than to a person.” The identity is stamped into the logs, and the logs can be watched in real time.

Spend caps. Administrators can set a hard limit on a project’s AI spend in the Cloud Billing Console. The project’s agent pauses when the cap is triggered, and work resumes with one click. Spend is tracked per project, so costs can be charged back to departments.

Policy and security. Rules are written once and apply to every agent, such as barring agents from documents classified as need to know. The post frames governance as four questions: who the agent is, what it is allowed to do, what it did and where you can see it, and what it should never touch.

Identity: an account is not an owner

A separate account solves a real problem. When an agent works through an employee’s login, its actions look like that employee’s, and revoking one disrupts the other. A separate identity lets security teams grant narrower access and switch the agent off without touching a person’s account. Analyst firm Futurum credits the design with giving security teams a clear line between human and agent actions.

What an account does not provide is an accountable owner: it does not say which person approved the agent’s permissions or answers when it gets something wrong. Google says an agent sees only what people share with it, which means someone is sharing, and that decision belongs to you. Our guide to AI agent governance puts inventory and scope of authority at the start of its framework for this reason.

The audit trail, and what it leaves open

An action-level log helps reconstruct what happened, and attributing entries to the agent keeps human and automated activity apart. It also raises a question the post does not address: how does a reviewer link an agent’s action back to the request, and the person, that set it off? That is our inference, not a gap Google has acknowledged.

A log only helps if someone reads it. A September survey published by Guild.ai, a vendor of agent management tools, and fielded by Morning Consult, reported that 39.8% have logging or audit trails and 31% have an automated kill switch. The release does not state the base for those figures and the research is vendor-sponsored, so treat them as indicative only.

Spend caps: useful, but thinly described

The post gives no time period, no alert thresholds and no figure for how quickly a cap takes effect. An earlier Google Cloud post on billing for agents, dated August 26, 2026, describes a firm monthly project cap, alerts at 50%, 80% and 100% of budget, and an optional overage setting. The October post does not say whether the same settings apply to the Gemini agent, so do not assume they do.

Two limits follow from how a cap works, and both are our reading. The cap sits at the project level, so one runaway agent could pause others sharing the project. And a cap limits cost, not harm: an agent can send a wrong message or delete a file at almost no cost, so caps sit beside permissions and approvals, not in place of them.

What independent voices say

Coverage so far is analysis of the announcement, not testing. Carmi Levy, an independent analyst quoted by CIO on October 8, said Google is trying to become “the gatekeeper of the new enterprise operating system.” He called Google arguably ahead on identity and audit trails, but questioned whether CIOs and CISOs can trust it with mission-critical processes.

Mahmoud Ramin of Info-Tech Research Group, quoted in the same article, said the announcement does not create a new category, and called enforcing governance non-negotiable.

Futurum, in an October 9 analysis, noted that Google says it does not intend to charge a per-seat license for coworker agents in Workspace, but has not said how it will meter agent activity.

What is and is not confirmed about availability

Google’s product page says “Not every feature shown on this page is available right now.” It lists delegating multi-step background tasks, mobile and desktop access, and third-party model choice as early access.

The Kurian post gives no general availability date, eligibility criteria or agent-specific price. It labels the Financial Services and Legal specializations as in preview, with Government, Healthcare and Retail coming soon. It does not label the core agent, coworker agents or spend caps as preview or generally available, so their status is unconfirmed. Futurum makes the same point: Google gave few general availability dates.

Reworked reports that a Google spokesperson told VentureBeat the agent comes at no additional charge where Gemini Enterprise is available. We did not find that in Google’s own posts, so treat it as reported.

Who owns the policy behind the controls

Google has built mechanisms: an identity, a log, a cap and a place to write rules. None of them decides anything. Someone still has to choose which agents may exist, which data counts as need to know, what each budget should be and who reviews the logs.

This is the point our CrowdStrike piece made about detection tools. A product can enforce a policy, but it cannot write one.

There is also a coverage problem. Google’s controls cover Google’s agent, while agents from Salesforce, Microsoft and others bring their own identities, logs and caps. Shared protocols help agents talk to one another, but as we noted in our look at MCP and A2A governance, they do not settle who is responsible. That belongs to a policy that sits above any one vendor.

Is your agent governance ready? A checklist

Use Google’s four questions as a test, whichever platform you run.

Who is the agent? Keep a register in which every agent has a named owner, a purpose and an identity of its own, not a shared login or a personal account.

What can it do? Grant the narrowest access that lets it do the job, name the data it must not open, and review access on a schedule.

What did it do? Retain logs long enough to reconstruct an incident, assign someone to review them, and record who requested each task.

What should it never touch? Write a short list covering regulated data, payments, deletion and external sending, then test that the controls block those actions.

Set a budget for each agent or project, and decide who is alerted and who may resume work. Rehearse the stop by timing how fast you can disable an agent and revoke its credentials. A short AI Readiness Audit can show which of these controls you already have.

What this means if you build or buy agents

For teams doing AI agent development, identity, scoped permissions, logging and spend limits belong in the requirements from the first sprint, because they are cheaper to design in than to add later. Teams working on generative AI development can use the four questions as a design review before an agent reaches production.

For AI automation that connects agents to CRM and finance systems, start with read-only access and add actions as controls prove themselves. Wider AI development programs should treat agents as production systems with an owner and a review schedule. Google’s preview focus on financial services and legal is a signal too: finance and banking and law firms should apply the strictest version of these questions.

Where this leaves you

The confirmed facts are these. On October 8, 2026, Google Cloud introduced the Gemini agent and said its agents have their own identities, including email, that every action is written to an audit trail attributed to the agent, and that project-level spend caps pause the agent when triggered. This is a vendor announcement that has not been independently tested. Google’s post gives no general availability date, eligibility rules or agent pricing, and some related features are in early access or preview.

The practical response does not depend on any one vendor. Treat identity, logging and caps as tools, and AI governance as the policy that tells them what to enforce. Decide who owns each agent, what it may touch, what it may spend and who reviews its record. That discipline supports AI automation and AI development alike, so write it down before the platform asks for it.

Frequently Asked Questions

1. What did Google announce on October 8, 2026?
Google Cloud introduced the Gemini agent in a post by CEO Thomas Kurian. Its governance claims include agent identities with email addresses, an audit trail attributed to the agent, and project-level spend caps.

2. Does the Gemini agent really get its own email address?
Google says so. In Workspace, a coworker agent gets its own account with an email address, calendar and Drive. It is a vendor claim, with no availability date given.

3. What does the audit trail record?
Google says every action is written to an audit trail attributed to the agent, not a person. The post does not describe log retention or how an action links back to the requester.

4. How do the spend caps work?
An administrator sets a hard limit on a project’s AI spend in the Cloud Billing Console, and the project’s agent pauses when it is triggered. The post gives no time period, thresholds or enforcement speed.

5. Is the Gemini agent available to everyone?
Not as far as Google’s pages show. The post gives no general availability date or eligibility rules, some capabilities are in early access, and some industry versions are in preview.

6. If I use Google’s agent, is my AI governance solved?
No. The platform supplies identity, logging and caps, but you still decide which agents exist, what they may access, what they may spend and who reviews their activity.

7. What should my company do first?
Answer Google’s four questions for every agent you run, name an owner for each, and write the policy before relying on any vendor’s controls.

If you want to know which of your workflows are ready for AI agents, and where the governance gaps sit, that is exactly what we look at in a free AI Readiness Audit.

Our earlier piece on MCP and A2A governance looked at the open standards that decide how agents connect to tools and to each other. This one looks at the layer underneath those standards, which is the model itself, and at a recent event that shows how quickly access to that layer can change for reasons that have nothing to do with your product.

On August 28, 2026, OpenAI announced that it will end Cursor’s access to its models on November 12. The immediate story is about two companies and an acquisition. The lasting story is about every business that has built a workflow on top of someone else’s model. Here is what is confirmed, what is disputed, and what a sensible response looks like.

What is confirmed

The sequence is short. SpaceX acquired Anysphere, the company behind the Cursor coding editor, in an all-stock deal reported at $60 billion, which closed on August 14, 2026. Two weeks later, on August 28, OpenAI published a post explaining its decision to end Cursor’s access to OpenAI models, with November 12, 2026 as the date.

OpenAI’s stated reason is trust. It said it cannot be confident that SpaceX will use its technology within OpenAI’s terms of service, and it pointed to a history of contract disputes involving Elon Musk’s companies, including, in OpenAI’s account, xAI’s violation of OpenAI’s own service terms. OpenAI also said it was giving the maximum notice its agreement allowed, which works out to a little over ten weeks, and that its contract included a limited window to cancel after a change of control.

OpenAI’s help center article adds practical detail. It describes November 12 as the end of a transition period and says the formal termination date will be confirmed later. The affected features are the local Chat and Agent modes that currently offer OpenAI models. The unaffected features are Cursor Tab and autocomplete, Auto model selection, Cloud and Background Agents, Automations, the Cursor CLI, and the Cursor API and SDK, all of which continue to use models supplied by Cursor.

Users who want to keep using OpenAI models have three routes. They can bring their own OpenAI API key, which is billed separately from any Cursor or ChatGPT subscription. They can install OpenAI’s Codex extension and sign in with a ChatGPT plan or an API key. Or they can connect through an AI gateway their organization already manages, such as Amazon Bedrock or Azure. One detail matters for budgets: a ChatGPT subscription does not include API usage, so a team that switches routes may see a new line item.

Anthropic responded quickly. Co-founder and Chief Compute Officer Tom Brown said the company will keep increasing compute to support Claude models in Cursor.

What is disputed or still unclear

Several points are less settled than the headlines suggest, and they are worth separating from the confirmed facts.

Cursor CEO Michael Truell said OpenAI models account for only about 5% of Cursor’s traffic. That is Cursor’s own claim, not an independent measurement, and DevOps.com reported that it was widely questioned on social media. Treat it as Cursor’s position, not as an established number.

Truell also said Cursor was in talks with OpenAI to find a solution. Nothing in the sources reviewed shows that those talks have produced an outcome, and no response from SpaceX appears in the coverage we could verify. The November 12 date could still change, either through negotiation or through the formal notice OpenAI’s help article mentions.

The $60 billion price and the August 14 closing date come from reporting on the deal. The OpenAI post and the help article do not discuss the price. So the accurate framing is that the deal was reported at that value.

None of this changes the central lesson. Even if OpenAI models are a small share of Cursor’s traffic, the event shows how a change of ownership can turn a supplier into a gatekeeper overnight.

Why this is not really a Cursor story

Every company that builds on a third-party model has the same exposure Cursor just discovered. The contract you signed can be ended by the supplier under conditions you do not control, and an acquisition, on either side, is one of the most common triggers. In this case the acquired party was the customer. It could as easily be the supplier, whose new owner may reprice, restrict, or retire the product you rely on.

There is also a competitive dimension. Within hours of OpenAI’s announcement, a rival lab publicly reaffirmed its support for Cursor. That is good news for the customer in the short term, but it moves the dependency instead of removing it. A team that swaps one model vendor for another is still exposed to the same category of risk, only with a different counterparty.

Treat model access the way finance teams treat any critical supplier. Ask who owns the vendor, what happens if that changes, how much notice the contract requires, and what your fallback is. Most engineering roadmaps never ask these questions, because the model feels like infrastructure. It is closer to a contract that can be ended.

Switching models is not a configuration change

The technical half of the risk is easy to underestimate. Standards like MCP and A2A make it easier to connect an agent to tools and to other agents. They do not make one model behave like another.

Analysts quoted by CIO made this point directly. Manoj Chandra Jha of Nord-IQ Research said prompts and agent instructions that work well with OpenAI models can produce different results with another model, which forces enterprises to retune both prompts and evaluations. Abhishek Satapathy of Avasant listed where the differences show up in coding agents: repository-level work, debugging, refactoring, test generation, multi-file changes, and tasks where an agent must inspect a codebase, make changes, run tests, and correct its own errors.

That list should look familiar to anyone doing AI agent development. Agents chain many steps together, so a small difference in how a model interprets an instruction can compound across a workflow. A prompt that produced clean output on one model can drift on another, with tool calls made in a different order, formats interpreted differently, or errors handled in a different way.

CIO also quoted Pareekh Jain, who advised enterprises to support multiple models, test alternatives regularly, and “avoid making important workflows too dependent on one model.” The word regularly matters. A fallback model that has never been tested is only a hope.

What resilience looks like

Cursor itself offers a useful example of preparation. Most of its product does not depend on OpenAI’s models at all. Tab completion, Auto selection, cloud agents, automations, the CLI, and the API all continue on Cursor-supplied models. A Forbes analysis argued that this reflects deliberate investment in its own coding model, Composer 2.5, built on open-source checkpoints, which lets Cursor treat frontier model access as something it can substitute. That is an analyst’s interpretation rather than a confirmed account of Cursor’s strategy, but the product structure supports the point. The features most exposed are the ones where users chose an OpenAI model by name.

Very few companies can train their own model. The principle still applies at smaller scale: keep the part of your product that users experience separate from the part that depends on a single supplier. For teams working on AI agent development, that usually means keeping business logic, tool definitions, and evaluation data in your own repository, and treating the model as a component you can replace. Prompts written for one model should be documented as model-specific, so nobody assumes they will transfer.

A practical checklist for model dependency

Whether you are building internal tools, customer-facing agents, or a full product, the same steps reduce the risk. This is the kind of work that belongs in any serious AI development plan from the start.

Inventory every model dependency. List each workflow, which model it calls, through which route, and under which contract. Include shadow usage, such as teams running personal API keys.

Put an abstraction layer between your application and the model. Route calls through one internal interface so that changing the model is a change in one place, not a rewrite.

Build an evaluation suite before you need it. A set of representative tasks with expected outcomes lets you compare a replacement model on evidence instead of impressions. This is the piece Jha’s comment points to, and it is the one teams most often skip.

Test a fallback model on a schedule. Run the evaluation suite against at least one alternative every quarter, and keep prompts tuned for it, not only for your primary.

Read the contracts. Look for change-of-control clauses, notice periods, usage restrictions, and pricing terms. Note who can end the agreement and under what conditions.

Understand the billing routes. As the Cursor case shows, subscriptions and API access are often billed separately. Know which one each workflow actually uses.

Assign an owner. Model dependency is a business risk, so it needs an owner outside the engineering team who reviews it alongside other supplier risks.

Where this leaves you

OpenAI’s decision on Cursor is confirmed, with November 12 as the announced end date, though the formal termination date and the outcome of talks remain open. The claim that OpenAI models are 5% of Cursor’s traffic is Cursor’s own. The wider point does not depend on either detail. Access to a model is a supplier relationship, and supplier relationships change when ownership changes.

For teams investing in generative AI development and agent workflows, the response is measured, not alarmed. Inventory the dependencies, build the evaluation suite, test the fallback, and review the contracts. The cost is a few weeks of engineering time. The alternative is discovering your dependency on a Tuesday afternoon with a ten week clock running.

Frequently Asked Questions

1. When does OpenAI stop providing models to Cursor?
Answer: OpenAI announced on August 28, 2026 that access ends on November 12, 2026. Its help center describes that date as the end of a transition period and says the formal termination date will be confirmed later.

2. Why did OpenAI end the agreement?
Answer: OpenAI said it cannot be confident SpaceX will use its technology within its terms of service, following SpaceX’s acquisition of Cursor’s parent company. It cited a history of contract disputes involving Elon Musk’s companies.

3. What still works in Cursor after the cutoff?
Answer: Cursor Tab, Auto model selection, Cloud and Background Agents, Automations, the CLI, and the API and SDK continue on Cursor-supplied models. The affected features are local Chat and Agent modes that offer OpenAI models.

4. Can developers keep using OpenAI models in Cursor?
Answer: Through other routes, yes. OpenAI lists bringing your own API key, using the Codex extension, or connecting through an AI gateway such as Amazon Bedrock or Azure. API usage is billed separately from a ChatGPT subscription.

5. Is it true that OpenAI models are only 5% of Cursor’s traffic?
Answer: That is what Cursor CEO Michael Truell said, but it is Cursor’s own figure and was questioned publicly. It has not been independently verified.

6. How can my business reduce model dependency risk?
Answer: Inventory every model dependency, put an abstraction layer between your application and the model, build an evaluation suite, test a fallback model regularly, and review supplier contracts for change-of-control terms.

If you want to know how exposed your own workflows are to a single vendor, that is exactly what we look at in a free AI Readiness Audit.