Zero-ticket data access: requests answered by policy
Every data access request becomes a ticket, a wait and a guess about who should approve. Data Workers answers requests against your policy, finds the least access that does the job, routes it to the right owner, and keeps an approval record for every grant.
Before and after
| Today | With Data Workers |
|---|---|
| A ticket for every data access request, worked in order | The request is answered in plain language, against your policy |
| Requesters ask for whole schemas because they cannot tell what they need | The agent finds the least access that answers the question |
| Nobody is sure who owns the table, so the ticket bounces | Each request goes to the owner who can approve it |
| Access that was meant to be temporary stays for years | Grants are time-boxed by default |
| An access review means reconstructing who approved what | Every grant has an approval record on file |
Access control is meant to be written once and applied the same way every time. In practice it lives in a queue, and each answer depends on who picks up the ticket. As AI agents and data access governance risks grow, the number of requests, human and agent, grows with them, and a queue cannot keep up.
How it works
1. Answer the request against policy
Someone asks for data in plain language. The Data Access & Governance agent runs check_policy against your written policy and enforce_rbac against your role model, so the answer comes from the same rules every time. The role-based and attribute-based models you already run stay as they are.
2. Route it to the right approver
request_governance_review finds the least access that answers the request and sends it to the named owner. They approve in the flow of work instead of working a ticket queue.
3. Provision with an approval record
Once the owner approves, provision_access records a time-boxed grant against that approval. generate_audit_report compiles who asked for what, who approved it and when it ends, whenever a reviewer wants it.
The impact metrics we move
- •Policy-covered request answered: from about a week to 5 min
- •Request routed to the right approver: from about 2 days to 10 min
- •Access evidence compiled for a review: from about 2 days to under 1 h
Where teams start
- •Analyst access to warehouse schemas. Snowflake, BigQuery or Databricks requests that today go through a ticket form.
- •Read access to sensitive domains. Finance, HR or customer data, where the owner always approves and the record matters.
- •Lake permissions on AWS. Lake Formation grants checked alongside warehouse access.
- •Agent and service access. Requests from AI agents and service accounts, held to the same policy as people.
- •Quarterly access reviews. Approval records ready before the review starts.
What powers it
The Data-Agents Swarm does the work: the Data Access & Governance agent checks, routes, provisions and reports, and the Identity agent supplies who is asking. The Connectors agent can list existing lake permissions with list_lf_permissions. The Autonomous Data-Conductor coordinates the hand-offs, Autopilot Standards keep a named approver on every grant, and the Spellbook Data Catalog holds the policy and the record. See how it shows up in data standards that enforce themselves, audit evidence on demand and audit logging. For the agent itself, read inside the Data Access & Governance agent.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis. L0 to L2 run today: agents answer, route and record, and a person approves. L3 and L4 are where a domain can go on evidence, once its record of approved grants earns it.
The pilot
- •Scope. One domain: the warehouse schemas behind your busiest access queue, with its owners named as approvers.
- •First week. Agents start by watching and suggesting. They read incoming requests and show the answer, the approver and the grant they would have proposed, with receipts.
- •By week two. Policy checks and routing run on their own for the whole domain; every grant still goes to a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Policy-covered request answered: from about a week to 5 min
- •Request routed to the right approver: from about 2 days to 10 min
- •Access evidence compiled for a review: from about 2 days to under 1 h
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Does it grant access without a person? No. A named owner approves every grant. The agent does the checking, routing and record-keeping around that decision.
Does the grant land in my warehouse? Applying a grant directly works on some platforms today. On the others the agent records the approved grant and hands it to your admin to apply. We confirm which applies to your stack in week one.
Do we have to replace our RBAC model? No. Your roles and policies stay the source of truth. Generating RBAC policies for Snowflake is a common first step if they are not written down yet.
What if the agent routes a request to the wrong owner? The approver can redirect it, and the correction is on record. Fixing routing is part of the first two weeks.
Is this the same as an RBAC tool? No. Role-based tools define who can do what. This handles the request, the approval and the record around it. See RBAC for data engineering.