Identity security for the agent era
Your people sit behind SSO and MFA. Your agents, API keys and MCP servers act with borrowed authority and nobody watching. Qbrin inventories the ones it is connected to, scopes what each can reach, and checks each consequential action an agent submits against evidence before the tool runs.
09:41:02billing-agentrefund_payment · ₹48,500Invoice + policy v3 matchALLOW09:41:07key · ci-deploymerge to mainNo approved change ticketHOLD09:41:11support-agentexport 2,140 patient rowsBlast radius above scopeESCALATE09:41:15mcp · driveread Q3 renewals deckIn the agent’s data scopeALLOW09:41:19ops-agentdelete staging bucketOwner left the companyESCALATEOne inventory for every identity that can act
The new attack surface
Identity security was built for people who sign in and click. Agents hold long-lived keys, inherit whoever launched them, chain sub-agents and call tools in milliseconds. The login was fine. The action is where it goes wrong.
An agent on a person’s token can do everything that person can.
Agents outlive the people and projects that created them.
A ticket or email can tell an agent to do something new.
By the time a log is read, the refund has already gone out.
The platform
The same three tabs your security team gets in the console, wired to one identity graph.
Discover
People, agents, keys, MCP servers and connectors in one inventory, each with an owner, what it can reach and a risk score you can read.
| billing-agentAgent | Priya S. | 3 tools | low |
| ci-deployAPI key | Platform | repo:write | med |
| ops-agentAgent | — none | 7 tools | high |
| drive-mcpMCP server | IT | drive:read | low |
Protect
Narrow each agent and key to the sources its job needs, then check each consequential action it submits: ALLOW, HOLD or ESCALATE.
Sample: over the last 30 days this scope would have cut 214 of 1,906 cited documents.
Defend
Injections, odd networks, ownerless agents and refused grants surface as detections, with a receipt behind every one.
The identity graph
Qbrin links every agent to the human who owns it, the human it is acting for, the keys and tools it holds, and the data those can reach. When something goes wrong you see the whole chain, not a lone API call.
Sample · support-agent · who and what it touches
Early accessCloud and identity providers
Beyond your agents
The same graph covers the people, service accounts and keys in the clouds you already run. qbrin connects read-only, reads inventory and audit logs on a schedule, and links what it finds to the agents and AI tools above.
dana@northwind.healthOkta · AWS · GitHub, linked by verified email and SAML
09:12OktaSign-in, new device, push approvedALLOW09:13AWSAssumeRoleWithSAML → prod-adminALLOW09:21AWSCreateAccessKey for ci-deployHOLD09:24GitHubPersonal access token created, org-wide scopeESCALATESession riskBehavior · Likelihood · Impact
A provider that cannot be read makes the score cannot score, never low.
Every identity, session, AI tool and the organisation gets Behavior, Likelihood and Impact, each with the reasons behind it. When a provider cannot be read, the score says so instead of guessing low.
One call, one verdict
Before a connected agent sends, merges, writes, deletes, pays or operates a computer, it asks Qbrin. The answer comes back with its reasons and a receipt.
Who is acting, who owns it, and whose authority it borrowed.
Org baseline plus per-agent allow, deny or ask-a-person rules.
Is the claim behind the action backed by a current source?
Does it carry a secret or credential that should not leave?
How many records, how much money, how hard to undo.
POST /v1/authorize
{
"action": "export_records",
"args": { "table": "patients", "rows": 2140 },
"evidence": [{ "kind": "ticket", "ref": "ZD-88213" }]
}
→ 200 OK
{
"decision": "ESCALATE",
"reason": "rows 2140 > policy limit 50 (PHI export)",
"stage": "policy",
"blastRadius": "external",
"receipt": "rcpt_7Hq…e21"
}The ticket was real and the agent was who it said it was. What it asked for was far more than the policy allows for patient data, so Qbrin escalated it to the owner with the evidence attached. The exact request and response fields are in the API docs.
One authorize call at the tool boundary, or through the MCP wrapper.
The verdict names the check that decided it and why, not one opaque score.
ALLOW returns an expiring signed grant; on HOLD or ESCALATE an integrated tool waits.
The receipt records the verdict, its reason and the evidence it was bound to.
Use cases
Give every agent an identity, an owner, a sandbox and a policy before it touches production.
Learn moreA scoped key can only call the MCP endpoint, where its data scope is applied. REST never sees the whole corpus.
Learn moreNarrow-only data scopes per agent and per key, with a preview of what they would have cut.
Learn moreInstructions hidden in emails, tickets and pages are filtered before a tool runs.
Learn morePayments, deletes and merges wait for their owner in Approvals, with the evidence beside them.
Learn moreReplay any decision with the identity, policy and evidence it was judged on.
Learn moreQbrin Labs
Qbrin Labs tests agents against real software (Wazuh, OpenPLC, the PX4 drone autopilot, payment APIs) and publishes the method with the results.
See every benchmarkQuestions
See it on your stack
In a 20-minute walkthrough we connect one source read-only, inventory the agents and keys that can act on it, and run one of your real actions through the gate.
or email hello@qbrin.com