Platform · Identity & Access
AI never gets more than you allow.
Every action is tied to the person who asked, or an agent account you chose, and stays within the role you gave them in Bazinga.
Problem
The shared key is the problem.
The fastest way to connect AI to a system is one key that can do everything, shared by every assistant. It’s also why security teams say no.
Everyone’s access, for everyone.
One key that can do everything means every person’s AI acts with everyone’s rights.
No one in particular.
When every request uses the same key, the record shows the key, not the person who asked.
Impossible to revoke cleanly.
Take back one person’s access, and you take back everyone’s.
Two ways in
An identity for every request.
Agents built for one job connect with a key of their own. People connect their own assistant, as themselves. Either way, Bazinga always knows who is asking.
For agents
Service keys.
Each purpose-built agent gets its own key, running as an account you choose, with that account’s roles. Revoke a key, and only that agent stops.
Typical: Copilot Studio agents, n8n flows, agents built with an SDK, scheduled jobs.
For people
Their own sign-in.
Each person connects their assistant once, signs in as themselves, and approves the connection. From then on, every action carries their name.
Typical: Claude and ChatGPT for every employee, and Microsoft 365 Copilot through Copilot Studio agents.
Enforce
The person’s role, enforced on every request.
AI doesn’t get a permission model of its own. It works within the person’s role in Bazinga, and what you expose can only narrow it.
Review cases · permissions
| Role | View | Edit | Delete |
|---|---|---|---|
| Finance clerk | Own entries | Own entries | None |
| Finance manager | All entries | All entries | None |
| Sales | None | None | None |
Down to the record.
For data kept in Bazinga, each role sees all entries, only its own, or none. For a connected system, the limit is built into the action, like only the accounts a person manages.
Down to the action.
Choose which roles may run each workflow through their AI.
Down to the field.
Leave a field out of what AI gets from a data set, even when people can see it on screen.
What a person’s AI can do = what their role allows.Minus anything you didn’t expose.
Who asks
A person or an agent.
Signed in as themselves, or connecting with a key of its own.
Bazinga
Checks, then records.
The role, record rules, fields, and actions are checked, and who asked is recorded.
Your system
Through its own connection.
Bazinga connects to each system with an account of its own. Its rights there are the outer limit for everyone’s AI.
Sign in
Sign in the way your organization already does.
The assistant connects to Bazinga, and the person signs in the way they always do: through any identity provider that speaks OpenID Connect, or several side by side, like Entra ID for staff and Okta for partners.
- Microsoft Entra ID
- Okta
- Google Workspace
- Auth0
- Ping Identity
- Keycloak
- Amazon Cognito
- AD FS
Your provider’s policies apply.
Multi-factor and conditional access rules work as they do everywhere else.
Groups become roles.
Map a directory group to a role, so AI access follows your directory instead of a second list to maintain.
Passkeys, too.
Where people sign in to Bazinga directly, passkeys and two-factor sign-in are available.
Control
Every connection, yours to revoke.
Decide which assistants may connect, who may connect them, and how much they may do.
Approved assistants only.
Choose which AI clients may connect: Claude, ChatGPT, Copilot Studio, or your own agents.
Roles that may connect.
Decide who may connect an assistant at all, before any action is considered.
Rate limits.
Limits for each person and each AI client keep a runaway agent from doing much.
Revoke in one place.
See every connected assistant and key, and disconnect any of them at once.
Related capabilities
Show your security team AI that follows their rules.
Bring your identity provider and one system. See every request arrive with a name, within that person’s role.