Skip to content
QDataCloud

Category

AI Agent Security

AI agents are non-human identities that call tools. They need identity, policy, and a decision on every action. This is not a chatbot wrapper and not prompt DLP as the core.

Product: QData Identity Security. Module label: AI Agent Identity Security. Broader set: Non-Human Identities.

Agents are a subset of NHI

An agent is an NHI. NHI also includes service accounts, workloads, machines, applications, bots, automations, and API identities. Do not use “NHI Security” as the name of the whole product — and do not treat this page as the whole product either.

  • Agents
  • Tools
  • MCP
  • Policies
  • Resources

What an agent does differently

Human IAM still waits for a person to sign in. An agent does not. It reaches APIs, data, SaaS, files, and MCP tools under its own identity. Standing roles and SSO sessions do not describe a tool call with arguments.

  • No human session

    The subject of the check is the agent, not the engineer who deployed it.

  • Tool calls are actions

    Authorize the tool as an action on a resource, with context — amount, environment, destination — not a blanket “agent role”.

  • MCP is a surface

    Model Context Protocol is how many agents reach tools. It is not the product engine and not a separate product name.

Treat the agent as a first-class identity

Give it an owner. Inventory the tools it can reach. Attach policy. Record a decision on each action. Least privilege for a person is not least privilege for an agent that fans out across tenants and MCP servers.

MCP path

Which agent identity may call which tool, with which arguments, under policy. Typical enforcement is an MCP gateway PEP. If that gateway is not on the path, you can still observe and simulate — you cannot honestly claim a block. The dedicated surface page is MCP Security.

  1. Agent
  2. MCP
  3. Tool
  4. Resource
Agent to MCP to tool to resource. MCP security is a surface of this product, not a separate product name.

Same decision model as other NHI

Agents do not get a special allow/deny dialect. The path often includes tools. The outcomes do not change.

  1. Agent
  2. Identity
  3. Authorization
  4. Policy
  5. Risk
  6. Decision
  7. Resource
The same allow / deny / approval decision applies to agents and to other NHI types.
  • 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.

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.

Where to go next

  • MCP Security

    Tools as resources. Gateway as PEP. Not the product engine.

    Open MCP Security

  • Non-Human Identities

    The rest of the NHI set — agents are the newest class, not the only class.

    Explore NHI

  • Authorization

    The same four-part check when the path is not MCP.

    Open authorization

  • QData Identity Security

    The product this category sits in: inventory through audit.

    See the product

Questions

No. It is a category page for agents as a type of NHI. The product is QData Identity Security. Broader NHI lives on the Non-Human Identities page.

Build with an authorization check

Start from the developers hub, or see how protection actually attaches.

Start buildingSee security