Project 02 of AURI · agentic AI for the enterprise

A permission-aware intelligence layer that knows what you're allowed to see.

AURI Access sits on top of Google Drive and uses Drive's own existing permissions as the access-control system — not a bolted-on guess. A deterministic Apps Script layer decides what a caller can actually see; Claude synthesizes a cited answer from only those documents. The model never sees what it wasn't already authorized to open.

01 — The premise

Company knowledge is scattered. The boundaries around it aren't consistently respected.

Company knowledge lives spread across Drive folders, with access boundaries that exist on paper but aren't consistently enforced in practice. Employees waste time hunting for the right document, and there's no single system that respects who's allowed to see what while still making that information easy to find.

Leadership-tier information — compensation, board discussions, strategic plans, sensitive HR matters — has to stay leadership-tier. Not because a tool is clever about it, but because it never leaves the boundary Drive's own sharing settings already define. The testbed is Meridian Analytics, a fictional B2B SaaS company, with department folders for Sales, Marketing, Finance, HR, and Operations plus a restricted Leadership tier.

02 — The design question

The design question

Everything in this project is built to answer one question, and it's a hard one because the two goals usually pull against each other — strict access control tends to make information harder to find, and easy discovery tends to leak.

Can an intelligence layer sit on top of a company's existing Drive structure, respect real permissions rather than guessing at them, and still give employees fast, cited, trustworthy answers?

03 — Architecture

Three layers, one hard rule

Each layer has exactly one job, and the boundary between them is the point of the whole design: enforcement is deterministic code, synthesis is the model, and the two never trade places.

Layer 1

Google Drive: System of Record

Folder structure mirrors the org chart — department folders (Sales, Marketing, Finance, HR, Operations) plus a Leadership-only tier. Access control is native Google Drive sharing, not reinvented. The system trusts Drive's permission model as ground truth: if Drive wouldn't let a user open a file directly, AURI Access won't surface it either, under any framing.

Layer 2

Apps Script: Deterministic Service Layer

Given a caller's identity, it walks real Drive folder permissions to determine what they can actually see. It never infers access — a folder that throws an error when the script tries to open it is Drive itself saying the caller can't see it. It extracts document content, flags operational hygiene issues (stale docs, duplicates, orphaned files), and logs every query to an audit trail.

Layer 3

Claude: Synthesis & Judgment Layer

Receives only the documents Layer 2 has already cleared. It synthesizes an answer with citations back to source documents, and is explicitly instructed to flag stale, duplicated, or ownerless documents as caveats rather than treating every source as equally reliable.

Code calculates and enforces. The model judges. The model never sees what it wasn't already authorized to see.

04 — How a query moves through the system

How a query moves through the system

Every answer follows the same path. The permission check and the authorized-documents filter both sit before the model — by the time Claude is involved, the question of what's allowed has already been settled by code.

Employee query Identity / permission check Google Drive Deterministic Apps Script layer Authorized documents only Claude synthesis Cited answer + data-hygiene caveats Audit log

05 — Permission architecture

Permissions are inherited, not reinvented

AURI Access does not create a parallel authorization system. Google Drive remains the source of truth; the intelligence layer inherits and enforces the permissions already defined there. Deployed as Execute as: User accessing the web app, every Drive call runs as the actual caller — so the ACL check is Drive's, made against the real person asking, not the script owner.

There is no invented permission model to keep in sync, no shadow copy of the org's access rules to drift out of date. A folder that errors on open is a denial, full stop.

Access is enforced before inference.

06 — Trust & governance

Trust & governance

Run live against a seeded Meridian Analytics Drive environment and a deployed Apps Script web app, the system has demonstrated the controls below — not as design intentions, but as observed behavior on real queries.

Enforcement

Deterministic permission validation

Real Drive ACL lookups, never an inferred or application-side permission model.

Enforcement

No inferred access

A folder that throws on open is Drive denying the caller — treated as a hard denial.

Enforcement

Leadership-only boundaries

Leadership-tier content stays in its tier, and content-level "do not surface" instructions are honored.

Answer quality

Cited responses

Every answer traces back to named source documents, not an unsourced summary.

Data hygiene

Stale-document detection

Outdated playbooks are flagged as caveats rather than presented as current guidance.

Data hygiene

Duplicate-document detection

Same-folder and cross-department redundancy is surfaced in the response.

Data hygiene

Ownerless-document detection

Orphaned SOPs with no listed owner are flagged for human review.

Auditability

Query audit logging

A semantic log of what was asked, returned, and withheld — distinct from Google's native Drive audit log.

07 — Relationship to AURI Finance

Project 02 of the same platform

AURI Access and AURI Finance are built around the same core discipline: hard boundaries between what the model decides and what deterministic systems enforce. The domain is different; the split is identical.

AURI Finance

AI reasoning + deterministic financial controls + human authority.

AURI Access

AI reasoning + deterministic permission controls + existing enterprise authority.

The domain changes. The architecture principle doesn't.

08 — Technical implementation

Technical implementation

For technical readers: the whole system is a single Google Apps Script web app plus a dedicated audit Sheet. No servers, no separate backend — the deployment boundary is also the security boundary.

Runtime
Google Apps Script web app with doGet / doPost entry points, deployed Execute as: User accessing the web app so every Drive call is scoped to the caller.
Permission traversal
getAuthorizedDocuments() iterates the configured department folder IDs via DriveApp.getFolderById(); an error on access is recorded as a withheld department, never worked around.
Document extraction
extractText() pulls content and metadata (owner, last modified, department) from each authorized file for synthesis and hygiene checks.
Synthesis
Claude via the Messages API (claude-sonnet-5), called with only the pre-filtered document set and instructions to cite sources and flag stale / duplicate / ownerless documents.
Citations
Answers reference source documents by name; data-hygiene issues are returned as explicit caveats alongside the answer.
Audit logging
logToAudit() appends a row per query — requester, question, documents returned, departments withheld, duration — to a dedicated Google Sheet, separate from Google Workspace's native Drive audit log.

Honest gap: the current deployment runs under a single Google account, so multi-user enforcement — two employees getting two different, correctly-scoped answers — hasn't been demonstrated against two distinct identities. The architecture is built for it (Execute as: User accessing the web app scopes every Drive call to the caller), but proving it needs a real Workspace domain rather than a personal account.

09 — What this demonstrates

What this demonstrates

One compact project, built end to end, exercising the capabilities an enterprise AI role actually asks for:

Enterprise AI architecture Permission-aware AI Deterministic controls Google Workspace integration LLM orchestration Enterprise knowledge retrieval Governance Auditability Human-centered system design