Identify the caller
A session or bearer token supplies the principal for the request.
Aventara Access1.0.0-rc.2 · RCKnow exactly who can do what.Every row. Every field.
Write role-first rules that follow your schema. Access decides which rows and fields a caller may use. Better Auth handles sign-in and credentials.
Release candidate·Read the documentation
A RULE. A CALLER. A DECISION.
access.policies.ts · excerptINPUT
.grants(({ grant, me }) => [ grant("signedIn", "update", "Note", { where: { authorId: me.id }, }),]).denies(({ deny }) => [ deny("*", "*", { if: { claims: { banned: true } }, }),]);Illustrative decisionGrant matches
Caller Ada · id user_adaAction update NoteRow authorId: "user_ada"Banned falseALLOW · author matches callerThe author can edit their own note. This is a local illustration of the quickstart rules.
Rules checked against your schemaDefault deny; matching denies winSessions, tokens and MCP agentsAudit the rule behind a decision
RULES YOU CAN REASON ABOUT
Who can do what should be easy to answer.
As your application grows, permission checks spread across handlers and services. Access gives those decisions a home: role-first rules, typed from your schema, with an explanation behind each decision.
01 / TYPE SAFETY
A typo should fail before a request.
Resource names, fields, relations and enum values are checked against your schema. Mistakes surface at the key that names them.
Explore the guide02 / DECISIONS
Permission is explicit.
Nothing is allowed until a grant allows it. Any matching deny wins, regardless of rule order. Missing values fail closed.
Explore the guide03 / PRINCIPALS
One engine. Every kind of caller.
Apply decisions to sessions, bearer tokens, MCP agents and server code. Agents are held to their user’s grants and token scopes.
Explore the guide04 / AUDIT
See the rule behind the answer.
Record authorization decisions in the audit log. Trace the rule that decided, so permission changes have a reason you can inspect.
Explore the guideTHE BIG PICTURE
Identity in. A decision out.
Better Auth handles sign-in and credentials. Access resolves permissions. The framework validates and runs the operation. Each part has a clear job.
Aventara AccessEvery decision follows your rules.Resolve the rules
Access evaluates grants and denies for the resource, action, rows and fields.
Enforce the decision
The framework applies the decision. Refused requests return 403 A4002.
MAKE IT YOURS
Give every permission a place.
Start with the Note example. Write your first rules, allow a request, and see another refused.
Build with AccessDoes Access sign users in?
Better Auth handles sign-in and issues credentials. Access adds authorization: which rows and fields a caller may use.
Can I use the authentication I already have?
Yes. Use the policy engine alone with your own authentication, add the Access plugin to your existing Better Auth setup, or set both up together with createAccess.
What happens when a grant and a deny both match?
The deny wins. Rule order does not change the result. A request with no matching grant is denied too.
Can several services share policies?
Each service can own a namespace in the Access registry. The CLI can push, pull and verify policy files; a generated client supports services that do not run on Aventara.