Skip to content
QDataIdentity Security

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" }
})
Conceptual example — not a live API contract.
What this check means

Agent invoice-agent wants payment.execute on payment:9281 in prod.

  1. 1. Subject

    invoice-agent is the identity that acts — not the engineer who deployed it.

  2. 2. Action and resource

    payment.execute on payment:9281 names the tool call and the object it wants to touch.

  3. 3. Context

    amount and env can flip the answer. Context is not a substitute for identity.

  4. 4. Outcome

    ALLOW, DENY, or REQUIRE_APPROVAL. A block needs a PEP on the path; shadow records the same decision without one.

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.

  1. Agent
  2. Identity
  3. Authorization
  4. Policy
  5. Risk
  6. Decision
  7. Resource
Agent to identity to authorization to policy to risk to decision to 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.

Runtime authorization

Runtime means the decision is asked when the action happens — not when someone last reviewed a spreadsheet of roles. A recorded event from yesterday is observe. A check on the path is authorize. A block is protect, and only where a PEP sits.

How observe differs from enforce is on the security model. This page does not repeat that essay.

  1. Observe

    A recorded event. Inventory, owners, shadow. Not a block.

  2. Authorize

    A check on the path: subject, action, resource, context.

  3. Protect

    A block — only if a PEP sits on the request.

Same loop. Protect is a path, not a heading.

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.

  1. Read

    Policy is human-readable. You can review who may do what before it runs.

  2. Version

    Change and roll back. Relationship rules stay in the same model.

  3. Simulate

    Same decision as protect — including would-be denies — without a block.

Shadow first. Enable protect after a PEP is on the path.

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.

Where a block can sit

A decision is not a block unless a policy enforcement point is on the request path. Without one you can still inventory, decide, and simulate — you cannot honestly claim protect.

  • SDK

    A check in the agent or service code, on the path of the action.

  • Security gateway

    A gateway that asks for a decision before the request continues.

  • MCP gateway

    Authorize which agent identity may call which tool, with which arguments.

  • Sidecar

    A process beside the workload that can allow or deny on the path.

  • Connector

    Enforcement in a system you already run — only when that connector exists.

SHADOWALLOWDENY

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 security

  • MCP Security

    When the action is a tool call on an MCP server.

    Open MCP Security

  • Developers

    Conceptual authorization.check, then SDK when packages are public.

    Start building

  • Pricing

    Platform tiers and NHI — not a per-check meter.

    See pricing

  • QData Identity Security

    The product this capability belongs to.

    See the product

Questions

No. Authorization is a capability of the product. This page is the commercial and technical explanation of the check — not a second SKU.

Start from a check

Use the conceptual example, or talk through where a PEP would sit on your path.

Start buildingSee security