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 discovers every one of them, scopes what each can reach, and checks every consequential action 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 companyDENYOne 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 every consequential action: ALLOW, HOLD or ESCALATE.
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 tamper-evident 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.
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, five checks
Before an agent sends, merges, writes, deletes, pays or operates a computer, it asks Qbrin. The answer comes back in milliseconds 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?
Time, network, session and what this identity normally does.
How many records, how much money, how hard to undo.
POST /v1/authorize
{
"identity": "agent:support-agent",
"on_behalf_of": "user:dev.r",
"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)",
"checks": {
"identity": "ok · owner Priya S.",
"policy": "risk · PHI export ≤ 50 rows",
"evidence": "ok · ZD-88213 fresh 4m",
"context": "ok · business hours, known ASN",
"blast_radius": "high · 2,140 patients"
},
"receipt": "rcpt_7Hq…e21 · chain #48213"
}The ticket was real and the agent was who it said it was. What it asked for was 40 times what the policy allows for patient data, so Qbrin escalated it to the owner with the evidence attached.
One authorize call at the tool boundary, or through the MCP wrapper.
Reasons come back per check, not as one opaque score.
ALLOW issues an expiring signed grant. HOLD and ESCALATE stop the tool.
Every decision is added to a tamper-evident chain.
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
Our research team runs real agents against real tools (Wazuh, OpenPLC, PX4 drones, payment rails) and publishes the method with every number.
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