Agent Identity & Governance

Every Agent Gets an Identity

Individual API keys, role-based access, column masking, and row-level security — per agent. Governance designed for autonomous systems, not just human teams.

HOW IT WORKS

Per-Agent Access Control

Each agent gets its own API key with configurable scope (read-only or admin). RBAC policies control which tables, columns, and rows each agent can access. Column masking redacts sensitive fields. Row-level security filters results based on agent identity. Every access is logged with the agent's identity for full auditability.

-- Create an agent-scoped API key
INSERT INTO _hatidata_keys
  (agent_id, scope, label)
VALUES (
  'agent_support_01',
  'readonly',
  'Support Agent - Tier 1'
);

-- Column masking policy
CREATE POLICY mask_ssn ON customers
  MASK COLUMN ssn
  FOR ROLE 'support_agent';

-- Row-level security
CREATE POLICY region_filter ON orders
  USING (region = current_agent_region())
  FOR ROLE 'regional_agent';

WHY IT MATTERS

Why Agents Need This

Least-Privilege by Default

Agents should only access what they need. Per-agent RBAC ensures a support agent can't read financial data and a billing agent can't modify customer records.

Auditability

Every query is logged with the agent's identity. When something goes wrong, you know exactly which agent did what, and when.

Regulatory Alignment

Regulators increasingly require explainable, controllable AI systems. Per-agent governance provides the control layer they expect.

COMPARISON

Legacy Approach vs ANDI

Legacy Approach

ANDI Approach

Shared database credentials
Individual agent API keys
Coarse team-level RBAC
Per-agent role-based access
No column masking for agents
Dynamic column masking per role
No agent-level audit trail
Full per-agent query logging
Manual access reviews
Policy-driven, automated governance

ANDI SUBSTRATE

Explore the Full Platform

Agent-Native Data Infrastructure.
Production-Ready Today.

Persistent memory. Isolated state. Verifiable reasoning. Through standard SQL.