Skip to main content
Identity Access Management (IAM) tells your systems who is allowed to read a piece of data. Purpose Access Management (PAM) tells your systems why that read is allowed — and then proves it.

The problem IAM doesn’t solve

A senior support engineer is allowed to read the customers table. That’s their role; that’s the IAM permission. But:
  • Should they read customers.ssn while answering an Email subject line “where is my package”?
  • Should they pull 50,000 rows in one query when their pattern is 1–5 rows?
  • Should an LLM agent acting on their behalf see the same set of columns as the human, or a smaller set scoped to “respond to one customer query”?
IAM can’t answer those questions. The role is “support engineer.” The data is “customers.” The decision should be “yes, but only the columns you actually need for this purpose, and only for the duration of this request.”

What Purpose Access Management adds

Inviolet introduces a third dimension between identity and data: purpose.
            ┌─────────────┐
            │   Purpose   │  ← "Reset a customer password"
            └─────────────┘

       ┌──────────┴──────────┐
       ▼                     ▼
 ┌──────────┐          ┌──────────┐
 │ Identity │          │   Data   │
 └──────────┘          └──────────┘
Every tool call an agent (human or AI) makes carries a declared purpose. The purpose is matched against policy: which data elements are allowed for this purpose, by this identity, at this time. The match is logged. The credential issued to fulfill the request has a TTL bounded by the purpose.

Why now

Three trends collapse onto each other to make PAM urgent:
  1. AI agents can do things 10,000 times faster than humans, and they don’t pause when something feels off.
  2. LLM-driven workflows generate tool calls a human never wrote — so the “purpose” is implicit in the prompt and gone the moment the LLM runs.
  3. Data sprawl means the question “should this query happen” requires judgment your DBAs no longer have time for.
PAM moves the judgment up the stack. The agent makes the request, declares a purpose, and the system says yes-with-scope or no-with-reason. The human oversees the policy, not every query.

What Inviolet ships

  • Intent extraction — every LLM tool call is parsed into a structured purpose record before it leaves the gateway
  • Policy engine — purposes are matched against declarative rules
  • Intent tokens — short-lived JWTs carry purpose context downstream
  • Database proxy — column-level enforcement at the query layer
  • Decision feed — every allow/deny is auditable and queryable in real time