Use Cases
One guarantee, many payoffs
ArtifactAuth ships inside your agent product to make one thing structurally true: a reader only ever sees what they're individually cleared for. Here's what that unlocks.
Safe cross-user agent memory
"Has anyone already looked into this?" A new user mines what the agent did for everyone else and sees only the parts they're cleared for. The reuse is real; the leak is not. And nobody had to trust the model to stay quiet.
Gated retrieval & search
Similarity search and tenant-wide cross-conversation retrieval are admission-filtered live against the acting principal, so a shared vector index can never return a hit above the caller's clearance.
Prove non-leakage to enterprise buyers
Every prospect asks AI vendors to 'prove your agent doesn't leak one user's data to another.' ArtifactAuth ships inside your product to make that guarantee structural, and demonstrable.
Compliance & audit for regulated teams
Fintech, health and legal teams building internal agents get an immutable, hash-chained ledger of every permit, deny, declassify and break-glass decision: evidence for auditors, not promises.
Fetch-time admission for tools
Brokered tools check authorization as they fetch, minting signed access receipts, so an agent's tool reads are gated before anything reaches the context window.
Live revocation that actually revokes
Because requirements are re-evaluated on every read, revoking a clearance immediately narrows what the same stored conversation will surface. No re-indexing, no stale grants.
However you model authorization
RBAC, ABAC, groups, channels: it's all one Requirement
You don't adopt a new permission model to use ArtifactAuth. Whatever you already run (Okta groups, roles, attribute rules, Slack channel membership, hierarchical clearances) compiles down to the same tiny boolean grammar (cap, all, any, not) and is resolved by your own policy engine, live per read or against a grant snapshot you push. Here's what that looks like for the models teams actually bring us.
Group-based
InternalA support-ops copilot at a B2B SaaS company where access follows Okta groups: reps sit in support, billing and oncall. Working a ticket, the agent pulls a billing runbook and a customer's payment history.
Each group is a capability. Those billing artifacts get labeled for the billing group, so a rep who isn't in it never sees them, even inside a thread a billing teammate started. Membership is resolved against Okta on every read.
{ "cap": "cap://acme/group/billing" }// cap://acme/group/<group>: <group> is a dynamic segment,
// so one adapter covers every group, not just billing.
const m = cap.match(/^cap:\/\/acme\/group\/(?<group>[\w-]+)$/)
if (!m) return "unknown" // a cap we don't own
const groups = await okta.groupsOf(principal.id)
return groups.includes(m.groups.group) ? "permit" : "deny"RBAC
ConfidentialAn internal analytics agent at a fintech with roles laddering analyst → manager → admin. A query returns a revenue-forecast row that only finance-analyst and above may read.
Roles are capabilities; the hierarchy is an any. And because a segment inherits the strictest thing that influenced it, the agent's one-line summary of that forecast is gated exactly like the forecast itself.
{ "any": [
{ "cap": "role://finance-analyst" },
{ "cap": "role://finance-admin" }
] }// role://<role>: <role> is dynamic; rank() encodes the ladder,
// and the any-of in the Requirement lets admin inherit analyst.
const m = cap.match(/^role:\/\/(?<role>[\w-]+)$/)
if (!m) return "unknown"
const mine = await roles.of(principal.id)
return rank(mine) >= rank(m.groups.role) ? "permit" : "deny"ABAC
SecretA healthcare scheduling agent where access is computed from attributes: a clinician may read a chart only if it's in their department and their license is active, a rule you can't freeze into a static list.
The Requirement stays an opaque predicate. ArtifactAuth never enumerates who qualifies. It just asks your PDP 'does this principal satisfy it, right now?' and the attributes get evaluated live at read time. Non-enumerable authorization works unchanged.
{ "cap": "cap://clinic/chart/1288/read" }
// your PDP decides via dept + license attrs// cap://clinic/chart/<id>/read: <id> is the dynamic chart id,
// resolved against the clinician's attributes, never a static list.
const m = cap.match(/^cap:\/\/clinic\/chart\/(?<id>\d+)\/read$/)
if (!m) return "unknown"
const c = await clinician(principal.id)
const chart = await charts.get(m.groups.id)
return c.dept === chart.dept && c.licenseActive ? "permit" : "deny"Channel-based
InternalA Slack-native assistant whose authorization is simply channel membership. It learns things in #project-atlas and #exec-planning, then a teammate who's only in #project-atlas asks it a question the next day.
Every segment is labeled with the channel it came from. Cross-channel memory reuse still works, but the exec channel's context can never surface to someone who isn't in that channel. No 'the bot repeated what was said in a private channel.'
{ "cap": "cap://slack/channel/C07EXPLAN42" }
// C07EXPLAN42 = #exec-planning// cap://slack/channel/<Cxxxx>: the channel id is dynamic,
// so the same rule gates every channel's memory by membership.
const m = cap.match(/^cap:\/\/slack\/channel\/(?<ch>C[A-Z0-9]+)$/)
if (!m) return "unknown"
const { members } = await slack.conversations.members({ channel: m.groups.ch })
return members.includes(principal.slackUserId) ? "permit" : "deny"Clearance / MLS
Top SecretA defense or regulated-enterprise agent using classic hierarchical classification (Public → Internal → Confidential → Secret → Top Secret) where a reader cleared to Confidential must never see a Secret paragraph.
This is ArtifactAuth's signature label: the chip you see across this site, with your own capabilities layered underneath each level. A compartment (need-to-know) is just an all of the level and the program capability.
{ "all": [
{ "cap": "clr://secret" },
{ "cap": "cap://acme/program-x" }
] }// two dynamic shapes: clr://<level> and cap://acme/<compartment>
const s = await subject(principal.id)
let m
if ((m = cap.match(/^clr:\/\/(?<lvl>\w+)$/)))
return s.clearance >= level(m.groups.lvl) ? "permit" : "deny"
if ((m = cap.match(/^cap:\/\/acme\/(?<comp>[\w-]+)$/)))
return s.compartments.has(m.groups.comp) ? "permit" : "deny"
return "unknown"Tenant isolation
ConfidentialA multi-tenant AI product whose first, non-negotiable rule is that one customer's agent memory can never reach another's: the baseline every enterprise buyer asks you to prove.
Tenancy is the base capability every segment carries, joined with whatever finer requirement applies. Cross-tenant retrieval can't return a hit by construction, because the shared index is admission-filtered against the caller's tenant on every search.
{ "all": [
{ "cap": "cap://tenant/acme" },
{ "cap": "cap://acme/group/billing" }
] }// cap://tenant/<t> and cap://<t>/group/<g>: tenant + group both dynamic
let m
if ((m = cap.match(/^cap:\/\/tenant\/(?<t>[\w-]+)$/)))
return principal.tenant === m.groups.t ? "permit" : "deny"
if ((m = cap.match(/^cap:\/\/(?<t>[\w-]+)\/group\/(?<g>[\w-]+)$/))) {
if (principal.tenant !== m.groups.t) return "deny" // wrong tenant
const groups = await okta.groupsOf(principal.id)
return groups.includes(m.groups.g) ? "permit" : "deny"
}
return "unknown"Have a cross-user leakage requirement to clear?
If prospects ask you to prove one user's data never reaches another, ArtifactAuth is how you answer structurally.