Overview

What Arkveil is

Arkveil is an authorization platform for backend applications. Instead of embedding access rules throughout the application, Arkveil defines them declaratively in a centralized access model. Coding agents author it, humans approve it, and the runtime enforces it.

One model answers both authorization questions:

• Can this user perform this action? — action authorization.
• Which data can this user see or modify? — data authorization.

Access is defined by attribute-based policies that live in the model, not by role checks hard-coded into the application. Policies are permit-only: access is denied unless a policy explicitly grants it. This is Zero Trust by design.

Arkveil does not handle authentication. It decides what an already-authenticated user may do.

Take a rule from an invoice service: "Managers can edit draft invoices from their own region." Without Arkveil, that sentence dissolves into if statements and WHERE clauses spread across endpoints, services, and queries. In Arkveil the rule becomes a few small policies. One permits the action for managers. Others constrain the data — only the manager's own region, only drafts — and compile into SQL that validates the write. Each policy is independently testable, and every decision is explainable.

The access model is explicit, centralized, testable, and machine-readable. Its behavior is observable and explainable. The same model remains the source of truth from authoring to enforcement.

Why authorization needs its own system

Authorization is security-critical logic: one missing or overly broad check can expose sensitive data or privileged operations. Yet it is usually implemented as ordinary application code — checks in controllers and middleware, role conditions in services, ownership lookups, tenant filters in queries, special cases in individual endpoints.

The consequence: the actual access model exists only implicitly, as the sum of thousands of implementation details. There is no authoritative answer to "who can do what?" Two endpoints meant to enforce the same rule can silently diverge, and a change in one place says nothing about the other access paths it affects. These checks become effectively write-only authorization logic: constantly added and changed, but rarely inspected or verified as one system. Application tests don't close the gap: they exercise individual execution paths, not the access model itself.

Agent-driven development amplifies the problem

Coding agents produce endpoints faster than any team can review the resulting authorization surface. An agent works from a local context and cannot reliably reconstruct every authorization assumption encoded elsewhere — while authorization correctness is a global property of the whole system. Each generated check may look reasonable on its own as the system-level model silently diverges. The more code is generated, the more a machine-readable source of truth matters: agents need the access model in a form they can inspect, reason about, modify, and validate.

What changes with Arkveil

Arkveil turns implicit authorization scattered through application code into an explicit access model.

• Explicit — the access model is a first-class artifact. Application code only marks enforcement points. Policies determine access.
• Centralized — one source of truth shared across services and endpoints, and available to both humans and agents working on them.
• Testable — policy tests describe significant access scenarios and protect them against regressions as policies change.
• Machine-readable — the whole model is structured data that fits into a coding agent's context and can be inspected and modified programmatically.

In operation, authorization becomes observable and explainable: every decision can be traced back through the targets, policies, attributes, and data that produced it.

Beyond these properties, one architectural principle: one model governs both actions and data. The same model decides whether an operation may happen and which rows it may read or modify. Policies can also query your database during evaluation, so an action decision can depend on its current state. For example, ownership of an invoice can be verified against the invoice table at decision time. Data-side rules compile into SQL and are enforced as part of the database operation itself, not as per-object checks after rows have been loaded. The same rule can govern an entire table without loading rows into application memory just to evaluate access.

The Arkveil access model

Simple primitives, orthogonal composition

Real-world access rules are complex enough on their own. The authorization system should not amplify that complexity. Arkveil keeps the model small — attributes, actions and datasets, targets, policies, tests. Complex behavior comes from composing simple concepts, not from multiplying rule kinds, effects, and combination algorithms.

Action policies and data policies have separate responsibilities: action policies decide which operations a user may perform, and data policies decide which data those operations may touch. Each policy expresses one concern. At enforcement time, the applicable action permissions and data constraints are evaluated independently and enforced together — a policy permitting managers to edit invoices never repeats the rule restricting managers to their own region. This keeps the number of policies close to the number of independent business rules rather than the number of combinations between them. Without the separation, every new action permission would multiply the data-specific variants that must be written and maintained.

Attributes

Policies reason over five attribute namespaces, evaluated at decision time:

Actions and datasets

Actions represent the protected operations of your application, and datasets represent its protected tables. Together they are the authorization surface Arkveil governs.

Targets

Targets determine where policies apply: a single action or dataset, a group selected through attributes such as action tags ("every billing operation"), or everything.

Policies

A policy grants access when its condition — an arbitrary boolean formula over attributes, literals, functions, comparisons, and boolean operators — evaluates to true. Policy semantics are deliberately permit-only:

• There is no DENY effect and no combination algorithms: access is granted when at least one applicable policy's condition is true, and denied otherwise. This removes a whole class of policy-combination conflicts.
• Adding a policy can only widen access — it cannot silently revoke or override an existing grant. That makes additive changes easy to reason about, and negative policy tests protect the boundaries that must stay closed.

A condition can also depend on the current state of your data. Take another rule from the same invoice service: "An invoice's owner has full access to their own invoice." As a formula, the ownership check is one line:

exists invoice where data.id = request.invoiceId and data.owner_id = user.id

It grants access when the invoice named by the request belongs to the requesting user — looked up in the invoice table at decision time, not copied into the request beforehand.

Tests

Policy tests are first-class artifacts. Each supplies a scenario — user and context attributes, request parameters, database row fixtures — and asserts the expected outcome. They turn security requirements into executable specifications that run independently of the application and protect intended behavior while policies evolve.

How authorization is enforced

Your application marks its enforcement points — middleware, decorators, or direct SDK calls — and the SDK sends authorization requests to the configured Arkveil endpoint. The authorization contract is the same in both deployment modes:

• Arkveil Cloud — the simplest integration path, with nothing extra to deploy.
• Arkveil Runtime — a local deployment mode for production systems that must stay independent of Arkveil Cloud availability, or whose policies query the database. It maintains a replica of the access model in your infrastructure and evaluates decisions there.

Three kinds of enforcement result come back:

• Actions — a granted / denied decision.
• Reads — a SQL condition derived from read policies, which your application adds to its own queries.
• Writes — a SQL check derived from write policies, executed by the SDK inside the mutation's transaction (before or after the write, depending on the operation). A failed check aborts the mutation.

Two kinds of SQL touch your database here. When a policy's condition depends on live data, the Runtime itself queries your database, over read-only connections, as part of evaluating the decision. Enforcement SQL is different: it always runs in your application's own database session — read conditions inside your queries, write checks inside your transactions.

One access model for humans, agents, and runtime

There is a single access model, and every participant works with it directly:

• Humans explore, edit, approve, and debug it in Studio.
• Coding agents work with it through the CLI: they inspect the existing model, add policies instead of inventing checks in application code, and run tests to verify the result. The agent extends the existing access model instead of inferring it from whatever code happens to be in its current context.
• Applications enforce it through the SDK and Runtime.

Adopting Arkveil

Adoption is incremental: protect one endpoint, let Arkveil coexist with your existing authorization, and expand at your own pace.

Arkveil also keeps an exit path open. A coding agent with CLI access has everything it needs to translate Arkveil enforcement points back into ordinary authorization code: every policy, target, and attribute schema is exportable, permit-only semantics map directly onto code, and policy tests specify the behavior the reconstructed checks must preserve — a complete, structured description of intent that the original scattered implementation never had.

Arkveil tools

Next steps

• Getting started — protect a first endpoint end to end.
• Coding agents — a new access rule, authored by your agent as policies and tests.
• Access model — attributes, targets, policies, and the semantics every decision follows.
• Action policies — protecting operations, from actions and targets to the enforced decision.
• Data policies — protecting data, from datasets to the SQL your application enforces.
• Policy tests — executable specifications that keep the model honest.
• SDK — the TypeScript SDK packages and how to integrate them.
• CLI — authentication, configuration, SDK codegen, and the full command reference.