Creating Bots

Bots

What's the difference between an agent and a bot?

An agent is an AI client a person is driving — they're signed in, and the agent acts inside their session. A bot is a non-human identity that acts on its own, with no person present: a CI job, a scheduled task, an autonomous agent.

If someone is at the keyboard, you want an agent connection. If nobody is, you want a bot.

Why not just let my CI job use my own connection?

Three things break. Its activity becomes indistinguishable from yours in the audit log. It inherits your policy treatment rather than getting its own. And revoking it means revoking your access too.

A bot gets its own identity, its own policy, and its own revocation.

How does a bot authenticate if nobody can log in?

Each bot is issued a client ID and client secret. Your deployment exchanges them for a bearer token using a standard OAuth2 client credentials grant against your gateway's token endpoint. Tokens last 30 days, so request a fresh one rather than storing one permanently.

I lost the client secret. Can I get it back?

No. It's shown once at creation and never again. Revoke that credential and issue a new one — it's a quick operation and the bot's other credentials and service authorizations are unaffected.

Can one bot have more than one credential?

Yes, and it's the recommended pattern — one credential per deploy target. Revoking one doesn't affect the others.

It's also how you rotate without downtime: issue the new credential, roll it out, confirm it works, then revoke the old one.

What can a bot do at a service?

Whatever you authorized, by one of three routes: a delegated OAuth grant where you pick the scopes before they reach the provider, a token you supply that belongs to the bot itself, or an AWS role grant with an optional IAM session policy.

I authorized a bot for an extra scope and it lost the others.

Re-authorizing replaces a bot's access rather than adding to it. Always authorize with the complete set of scopes you want the bot to end up with.

What happens when I revoke a bot?

Every credential stops authenticating and access to every authorized service stops immediately. This can't be undone — you'd need to create a new bot.

The revoked bot stays visible in your Bots list, marked as revoked, so the audit record of it is preserved.

Should a bot default to Allow or Deny?

The creation flow pre-selects Allow. For an unattended bot, Deny is usually the safer starting point — you open up specific actions as you confirm what the job actually needs.

Deny doesn't prevent discovery: the bot can still list its services and tools, so you get meaningful errors rather than an empty catalog.

Who's accountable for what a bot does?

Every bot has an owner — the person who created it. Bot activity appears in Activity attributed to the bot by name, with the owner recorded alongside it.

How do I see what a bot has been doing?

Filter Activity by the bot's name. Worth doing in the first week after deploying a new bot, while you still remember what you expected it to do.