Capability
Authorization
Decide what an agent or other non-human identity may do — at the time of the action — with policy, optional risk, and a policy enforcement point when you need a block.
This is a capability of QData Identity Security, not a second product. Runtime authorization is the check in the loop, not a banner on a dashboard.
The check has four parts
Standing roles and human SSO do not describe a tool call. The question is always the same shape.
Subject
The identity that wants to act: an agent or another NHI — not the human who deployed it.
Action
What it wants to do. A tool call is an action. A payment execute is an action. A blanket role is not.
Resource
What it wants to touch: a payment, a file, an API, an MCP tool. Tools are resources.
Context
The extra that changes the answer: amount, environment, tenant, arguments. Context is not a substitute for identity.
authorization.check({
subject: "agent:invoice-agent",
action: "payment.execute",
resource: "payment:9281",
context: { amount: 240, env: "prod" }
})From identity to decision
Policy is readable and versionable. The outcome is allow, deny, or require approval. Relationship-based rules can describe who may touch what — without making the engine a brand name on this page.
- Agent
- Identity
- Authorization
- Policy
- Risk
- Decision
- Resource
- ALLOW
The subject may perform the action on the resource in this context.
- DENY
The subject may not. In shadow, this is recorded as a would-be deny. In protect, a PEP can block.
- REQUIRE_APPROVAL
The action waits on a human. That is a decision outcome, not a notification after the fact.
Policy you can simulate
Policy-based access is something you can read, version, and run in shadow before protect. Simulate produces the same decision, including would-be denies, without blocking the caller. Enable enforcement after a PEP is attached.
Risk informs. It does not replace.
Risk in the first release is rule-based. It can change confidence around a check. It is not the policy decision point. A language model may help explain a draft. It does not issue allow or deny.
Least privilege for agents is not least privilege for people
A person with a role still acts as one session. An agent fans out across APIs, files, SaaS, and MCP tools. Least privilege is a baseline on the identity, then a decision per action — including which tool, with which arguments, in which tenant.
Observation is not enforcement
A decision is not a block unless a PEP is on the path: SDK, gateway, MCP gateway, sidecar, or connector.
Related pages
Security model
A decision is not a block without a PEP. Shadow before protect.
See securityMCP Security
When the action is a tool call on an MCP server.
Open MCP SecurityDevelopers
Conceptual authorization.check, then SDK when packages are public.
Start buildingQData Identity Security
The product this capability belongs to.
See the product
Questions
Start from a check
Use the conceptual example, or talk through where a PEP would sit on your path.