Your infrastructure, one conversation away

Ask claude.ai to check why a deploy is failing, or tell a coding agent to roll back a bad release without leaving your editor. That's the AI story we set out to build — and the part worth saying plainly is that there's no separate, less-audited path underneath it. A model reaches your infrastructure through the exact same role-gated API a human clicks through in the dashboard.

Three ways in, one API underneath

However you connect an AI to your org, it lands on the same catalog of tools, the same org roles, and the same audit trail. Three doors, one house:

Connectors: paste a URL, sign in, done

Connector setup landed in July 2026 and is deliberately boring. Paste the one MCP URL into claude.ai's or ChatGPT's connector settings, and the client discovers everything else itself over standard OAuth 2.1 metadata and registers itself on the fly — no manual client setup on either side. You're redirected to sign in to Sproobo if you aren't already, then to a one-screen consent page naming the connecting client and asking which of your organizations it should act in.

Approving mints that connector a token bound to your account in that org — it can do only what you personally can do there: reads free, writes plan-first, nothing above your own role. Team & Access → Connectors lists every connected client and lets an ADMIN revoke any of them on the spot, immediately and irreversibly. Full mechanics — token lifetimes, PKCE, rotating refresh tokens — are on AI & MCP connectors.

The CLI and the Agent Skill: same rules, a different door

Not every AI workflow lives in a chat client. sproobo is a single binary that signs in the same way a human does:

sproobo login
sproobo login --paste
sproobo login --token sk_…

A coding agent can't click through a browser prompt itself, so the Agent Skill — curl -fsSL https://cp.sproobo.com/skill/install.sh | sh — is built around that gap: its first instruction is sproobo whoami, and if that fails on auth, it asks you to run sproobo login yourself rather than attempting the browser step for you. From there it walks the agent through the plan-first model, idempotent retries, and which operations need you to say so explicitly — the same rules restated as instructions an agent reads before it acts, not a separate policy layer. Details on CLI reference and The Agent Skill. A tool that already speaks MCP natively can skip both and run sproobo mcp as a stdio bridge instead — same catalog, same gate.

The same audited API, not a shortcut for machines

Every one of those three doors passes through the identical role gate the dashboard uses. Reads are always free — list servers, list apps, tail a deployment's log, list secret names (never values). Writes are plan-first: a call without approve:true never mutates anything, it just returns a typed PLAN describing what applying it would do. Re-issue the identical call with approve:true to apply it.

And every applied AI write is tagged actorType: ai in the org's audit log, sitting right next to the human dashboard actions and CLI writes it's interleaved with — nothing about the record marks it as second-class or hides it from an audit export. A correlation id travels with every write too, so a retried call from a flaky agent replays the stored result instead of re-applying it.

The one write that doesn't auto-apply

Exactly one tool in the entire catalog is destructive: an in-place major-version engine swap on a backing service, restored from a backup that's resolved server-side rather than passed in the call. Everything else — deploying, rolling back, provisioning a service, setting a secret — is a plan-first write like any other, and a key minted in the dashboard can even opt into auto-applying those. That opt-in never extends to the destructive one, by design: called without approve:true, it parks as a pending approval that any ADMIN can open, review the exact arguments on, and apply or reject.

It isn't that nothing can ever apply it in one call — an explicit approve:true from a sufficiently privileged caller still will, the same as any other write. It's that neither the CLI nor the Agent Skill will pass that flag on your behalf unless you explicitly asked for that exact destructive action in the conversation; both are built to submit the plan-only form and show it to you first. The guarantee that actually holds is narrower and, we think, more honest than "AI can never do this": the automatic, no-human-in-the-loop path simply never covers it.

Why this is the whole point

None of the three doors above needed a separate, AI-flavored permission system to exist. They needed the API a human already uses to be complete and well-typed enough that a model could drive it safely through the same gate — same roles, same plans, same audit trail, one destructive tool carved out the same way for everyone. Add the connector, sign in to the CLI, or install the skill; the infrastructure underneath doesn't know the difference, and neither should you have to worry about it.