QData Identity Security
Identity Security for AI Agents and Non-Human Identities
QData Identity Security on QData Cloud is for organizations that run AI agents and other non-human identities. Agents reach APIs, data, SaaS, files, and MCP tools without a human login session.
They need identity, governance, authorization, least privilege, runtime controls, and audit. Human IAM still waits for a person. Service accounts never leave.
Discover. Govern. Authorize. Protect where a PEP exists. Audit every decision. Shadow first.
Shadow first. Enforcement only where a PEP exists.
authorization.check
SHADOWThe control loop
One loop. Two planes: observe, then enforce — only on an enforcement path.
Discover
Find agents and other non-human identities before they sprawl across tenants.
1 / 5
Govern
Give each identity an owner, a lifecycle, and a least-privilege baseline.
2 / 5
Authorize
Decide allow, deny, or require approval for a subject, action, and resource.
3 / 5
Protect
Block only where a policy enforcement point sits on the path.
Requires a PEP
Audit
Keep an immutable trail of decisions. Evidence is a log, not a badge wall.
5 / 5
What you operate
- Agents
- NHI
- Owners
- Applications
- Tools
- Resources
- Policies
- Risk
- Events
- Blocked actions
- Approvals
- Integrations
Identity models that assume a human session fail the agent
The problem
Agents act without logging in. Standing roles and human SSO do not describe a tool call.
The landscape
AI agents are the new NHI class — not the whole NHI class. Service accounts, workloads, machines, bots, and APIs already hold access. See Non-Human Identities.
Why existing IAM is insufficient
Least privilege for a person is not least privilege for an agent that calls tools across tenants, MCP servers, and internal APIs.
One loop. Two planes: observe, then enforce.
Inventory and policy without a PEP still matter: you can see owners, orphans, and would-be denies. Protection is a path, not a dashboard.
AI Agent Identity Security
Treat agents as first-class identities: owners, tools, and a decision on every action.
Open AI Agent Identity SecurityNHI Management
Cover service accounts, workloads, machines, bots, and APIs — not only agents.
Open NHI ManagementInventory
If it can act, it must be findable. Flag orphans before they become standing access.
Open InventoryIdentity Governance
Lifecycle and ownership for non-human identities, without a spreadsheet sidecar.
Open Identity GovernanceAuthorization
Allow, deny, or require approval for a subject, action, resource, and context.
Open Authorization
If it can act, it must be findable
Register agents and other NHI, discover what already exists, and flag identities with no owner. Inventory is the start of governance, not a CMDB screenshot. Without a connector, you register what you know or report through an SDK.
Inventory and governance on the product pageEvery identity needs an owner
Lifecycle for non-human identities: create, review, expire, revoke. Organization owns users. Tenant owns agents, NHI, policies, and resources.
Organization and tenantAllow, deny, or require approval — per action
Runtime authorization is the decision at the time of the action, for a subject, resource, and context.
Authorization — the check- Agent
- Identity
- Authorization
- Policy
- Risk
- Decision
- Resource
Protection is a path, not a dashboard
PEP surfaces: SDK, security gateway, MCP gateway, sidecar, or connector. If none of these is on the path, you can still observe and simulate — you cannot honestly claim a block.
How protection worksObserve
Inventory, owners, decisions, shadow. Seeing an event is not a block.
Enforce
A PEP on the path: SDK, gateway, MCP gateway, sidecar, or connector.
MCP tools are resources. Authorize them that way.
Model Context Protocol is a tool-runtime surface: which agent identity may call which tool, with which arguments, under policy.
MCP Security- Agent
- MCP
- Tool
- Resource
Risk informs the decision. It does not replace it.
Risk in the first release is rule-based. A language model may help explain a draft. It is not the final policy decision point.
Risk on authorizationWho this is for
Software houses
Many agents across many customer tenants under one Organization.
Software housesAI product teams
Developers who need a first authorization check, not an enterprise IGA program first.
DevelopersSecurity programs
Mid-market teams that need inventory, owners, shadow, then protect.
Security model
Register an agent. Check authorization. See the decision.
API-first. The snippet is conceptual until the public API host is live.
authorization.check({
subject: "agent:invoice-agent",
action: "payment.execute",
resource: "payment:9281",
context: { amount: 240, env: "prod" }
})You see identities, policies, and decisions — not the engines
Customer-facing nouns stay market language. Internal engines are not brand. Connectors appear when a connector exists — no logo wall until then.
Observation is not enforcement
QData Identity Security can inventory identities, evaluate policy, and record a decision. It blocks an action only when a policy enforcement point is actually in the request path. Shadow mode shows what would have been denied before you enable protect.
Evidence is an audit trail, not a badge row
We do not display unverified ISO or SOC marks. Residency and audit capabilities will be stated when they are confirmed for a deployment. Full prompts are not a default payload to the SaaS.
Choose a path
Security
See how observe differs from enforce, and where a PEP is required.
Developers
Start from a conceptual authorization check, then the SDK when hosts are live.
Business
Software houses and mid-market teams: talk through tenants, rollout, and quote.
Questions
Start from inventory, or start from the SDK
The product console is not public yet. Use the contact form, or explore the security model while hosts come online.