Security
The controls behind every read.
This page lists the access checks and data controls in Anuvrit, with the engineering document behind each memory control. We do not claim any security certification.
Access is checked on every read.
Who may read what is decided by the server, from the credential, each time memory is read or a job runs.
Tenant and scope checks
Server-side authorisation checks the caller, owner, project, capability, expiry and connector grant on every API call and job step.
Captured text is only data
Instructions found inside captured sources are treated as untrusted data. They do not change routing, authorisation or tool use.
Short-lived credentials
Client credentials are scoped to the capabilities they need and last at most 15 minutes before they are rotated.
Where it runs, and its limits.
The facts about hosting, and the limits we have written down.
Data region ap-south-1
The production service runs on AWS in the ap-south-1 region. Runtime secrets are read from AWS Systems Manager.
This site holds no database access
The public website has no database credentials. Waitlist requests go to the service, which validates them.
Known gaps are listed
Where a control does not yet cover a path, the security document names the gap and the follow-up.
Isolation and data controls.
How grants, refusals, archived content, secrets and deletion are handled.
Checks on every graph traversal
Grants can be limited to named repositories. Graph visibility, histories, citation opening and the re-checks around each answer apply that limit.
Refusals are audited
Every refused request is recorded with hashed identifiers and a reason. No token, query text or tool argument is stored.
Archive kept per client
Archived content is deduplicated only within one owner and project, so no stored object is shared between tenants.
Secrets are kept out
Text captures and connector items that contain keys, tokens or passwords are rejected. Generated summaries, graph labels and answers are redacted. Findings record the rule and position, not the secret.
Supersede, revoke, purge
Superseding keeps history. Revoking hides evidence from every read. Purging deletes it and what was derived from it, and stored answers that cited it are replaced.
Deletion stays inside its scope
Archive clean-up runs under one owner and project, cannot remove bytes another tenant or source still uses, and samples stored data for integrity.
The documents named here are in our private engineering repository. Write to us and we will share the relevant sections.
The Specialised Router on your machine.
The router runs your own agents with your own permissions. These are the controls around it.
Credentials stay on your machine
The router uses the CLIs you signed into, or your API keys, on your own machine. The cloud never sees provider tokens or keys.
Handoff packets hold no transcripts
A handoff packet carries the task state only. It is bounded in size, scanned for secrets before it is stored and holds no transcripts.
Plans and memory are information
Plans and memory excerpts are treated as information, never as commands. The router runs only your coding tools, with your own permissions.
Protected branches stay protected
The router stops at the line you set for each repository and never pushes to a protected or default branch.
Give your agents your team’s history.
Anuvrit is in beta and opening to engineering teams in stages. Join the waitlist and we will contact you when there is a place for your team.