Gazebo
    ServicesAgentsDocsSpecWritingPricing
    Log inSign up
    Log in
    GazeboBlogWe built the OAuth consent screen for AI agents

    We built the OAuth consent screen for AI agents

    Sharing an agent config today means handing over a README and hoping for the best. We shipped the infrastructure that OAuth gave web apps: declared scope, an explicit consent moment, and access that belongs to the installer — not the author.

    July 27, 2026·6 min

    Someone sends you a link to an agent they built. You click it.

    What happens today? You get a README. Maybe a .env.example file. A list of API keys to fill in. You paste your Stripe secret key into a config file, cross your fingers, and run the agent. You have no idea what it can actually do with that key. You're trusting a stranger with your production billing system.

    This is where agent sharing is right now. And it's the same place web app access was in 2005.


    OAuth solved this problem for web apps

    Before OAuth, if you wanted an app to access your data, you handed over your password. The app could do anything your account allowed. There was no scope, no consent moment, no way to revoke access without changing your credentials.

    OAuth changed the model with one insight: access should be declared, explicit, and user-controlled.

    The consent screen — that familiar list of permissions, the Approve button — wasn't just a UX decision. It was an architectural one. The app declares upfront what it needs. The user grants access from their own account. The app author never touches the user's password. And the user can revoke anytime, independently.

    The web scaled because of this trust model. Thousands of third-party apps connect to Google, GitHub, Stripe, and Slack — and users let them, because the consent screen makes the access visible and bounded.

    Agents need the same thing.


    The gap with agents

    An AI agent isn't meaningfully different from an OAuth app in terms of what it needs: access to specific services, specific operations, scoped to what its task requires.

    But there's no consent infrastructure. When someone shares an agent today:

    • The scope is implicit — you find out what it can do by reading the code or running it
    • The credentials are yours to manage — you paste them in, you're responsible for them
    • There's no revocation path — you gave the agent a key; changing that means rotating the key
    • The author has no accountability surface — nothing requires them to declare what they're asking for

    The technical capability to build agents has outrun the trust infrastructure to share them safely. We built Gazebo to close that gap.


    What we shipped

    Today we're releasing agent sharing — the consent screen for AI agents.

    Publish an agent with a declared scope. When you publish an agent from your Gazebo account, you declare exactly which services it needs and what operations it performs. That scope is locked at publish time — it can't be silently expanded later. The agent gets a versioned, signed identity.

    Anyone with the install link sees the consent screen. Before approving anything, the installer sees the agent's name, what it does, and a line-by-line breakdown of every service and operation it's requesting access to. Same pattern as OAuth — no surprises.

    Access is issued from the installer's own vault. When they approve, a scoped bearer token is created in their account, against their connected services. The agent author never sees, stores, or retrieves the installer's credentials. The installer's Stripe key stays in the installer's vault.

    Full audit trail, one-click revocation. Every credential access is logged in the installer's own audit trail. They can revoke the agent's access at any time, independently of the agent author. No key rotation required.


    The open standard behind it

    We also published the Agent Identity Protocol (AIP) — the open specification for agent identity that makes this work.

    AIP defines how an agent declares its identity and scope in a signed manifest, how a platform verifies that declaration, and how consent tokens are issued and scoped. It's the same role OAuth plays for web apps: a standard contract that any platform can implement, so the trust model isn't proprietary to Gazebo.

    We published it open because the identity infrastructure for agents shouldn't be one company's product. If other agent marketplaces, IDEs, and platforms implement AIP, agents become shareable across the ecosystem with consistent trust guarantees — the same way OAuth made apps portable across services.

    The spec is at gazebohq.com/spec. It's Apache 2.0 licensed. We'd rather have a good standard win than have Gazebo be the only place agents can be trusted.


    Try it

    If you have a Gazebo account, you can publish your first agent from the Agents page. Set the scope, get the install link, share it.

    If you don't have an account yet, sign up free — the sharing feature is available on all plans.

    And if you want to see what the consent screen looks like from the other side, here's a real install link for a demo agent: try the consent flow.

    Frequently asked questions

    What is the Agent Identity Protocol (AIP)?

    AIP is an open standard for AI agent identity. A published agent declares its name, version, and required service scopes in a signed manifest. Any platform that implements AIP can verify the agent's identity and scope before granting credentials — the same way OAuth lets any app request access to user data through a standardised flow.

    How does Gazebo agent sharing work?

    You publish an agent from your Gazebo account with a declared scope — the specific services and operations it needs. Anyone with the install link sees a consent screen listing exactly what the agent is requesting. They approve from their own vault; a scoped bearer token is issued to their account. The agent author never has access to the installer's credentials.

    Is the installer's data safe when they install a shared agent?

    Yes. The installer grants access from their own Gazebo vault — the agent author never sees, stores, or retrieves the installer's credentials. Every access is logged in the installer's own audit trail, and they can revoke at any time, independently of the agent author.

    Can the agent author expand the scope after installation?

    No. The scope is declared at publish time and locked. If the author publishes a new version with a wider scope, existing installs are unaffected. Installers would need to review and approve the new version separately.

    Related reading

    OAuth 2.0 for AI Agents: Client Credentials ExplainedAI Agent Credential Management: Provision, Audit, RevokeLeast Privilege for AI Agents: A Practical Guide

    Give your agents the access they need

    Scoped credentials, audit logs, one-click revocation — for every AI tool you run.

    Get started free
    ← Back to blog
    Gazebo

    IAM for AI agents. Scoped credentials, access policies, and audit trails — without rotating keys.

    Product

    • Pricing
    • Status

    Explore

    • Services
    • Agents
    • Workflows
    • Integrations

    Content

    • Writing
    • Topics
    • Blog
    • Docs

    Free Tools

    • Scanner

    Company

    • About
    • hello@gazebohq.com
    • security@gazebohq.com

    © 2026 Gazebo. All rights reserved.

    PrivacyTermsSecurity