Compliance
A compliance profile is a set of rules your team must follow, for example for ITAR, SOC 2, GDPR, HIPAA or your own internal policy. AnyDB checks each rule against your team as it is now and reports what does not comply.
- A check is read-only. It looks at shares, sign-ins, members, settings and credentials, and changes nothing.
- Every rule gets a clear answer: Pass, Fail with the records, people or settings at fault, or Cannot check with the reason. A rule AnyDB cannot verify is never reported as passing.
- Rules are typed, not free text. The same profile gives the same answer every time, whether a person runs it, an AI assistant runs it through MCP, or an AI Teammate runs it on a schedule.
Starter templates are a starting point, not legal advice or a certification. A regime's full requirements go beyond what AnyDB can see. Review every rule with whoever owns compliance in your organization.
Opening Compliance
Open Manage Team → Compliance. Only team admins can manage compliance profiles.
Creating a profile
- Choose a starter template under Start from a template, then select Add profile.
- Select Edit to rename the profile, change the values of its rules, remove rules, or add rules from the catalog.
- Select Save.
A team can hold several profiles at once, for example an ITAR profile and an internal policy.
Which workspaces a profile covers
By default a profile covers the whole team. To limit it, tick the workspaces it covers under Workspaces when you edit it, for example only the workspaces holding export-controlled data. Findings from other workspaces are then left out. Team-wide settings, such as single sign-on, members, API keys and connected apps, are always checked, because they apply to every workspace.
Starter templates
| Template | What it covers |
|---|---|
| ITAR (starter) | No public shares and no personal data on shares; shares expire within 30 days; sign-ins only from the US; single sign-on with allowed domains; multi-factor sign-in; no export over 1,000 rows. Add your allowed member and guest domains. |
| SOC 2 access controls (starter) | Single sign-on; multi-factor sign-in; admins active within 90 days; no API key unused for 90 days; only verified connected apps; no more than 20 failed sign-ins per address in 7 days; shares expire within 90 days. |
| Personal data protection (starter) | No share exposes personal data; public shares only without personal data; shares expire within 30 days; no export over 1,000 rows. |
Rules you can use
| Rule | What it checks | Values |
|---|---|---|
| No public shares | No record or form is shared by public link. | Optionally allow public shares that expose no personal data. |
| Public sharing turned off | The team does not allow public sharing at all. | |
| Personal data is not shared | No share exposes personal data (see below). | |
| Shares expire | Every share has an expiry no further away than this. | Days |
| Members from allowed domains | Every member's email is in one of these domains. | Domains, e.g. example.com |
| Guests from allowed domains | Every guest's email is in one of these domains. | Domains |
| Single sign-on | Team single sign-on is set up and on. | Optionally require allowed domains on SSO |
| Multi-factor sign-in | Always reported as Cannot check: AnyDB has no multi-factor sign-in of its own. Enforce it in the identity provider behind team SSO. | |
| Sign-ins from allowed countries | Every sign-in in the period came from one of these countries. | Country codes (e.g. US), days to look back |
| Few failed sign-ins | No address has more failed sign-ins than this in the period. | Count, days to look back |
| Admins are active | Every owner and admin was active within this many days. | Days (up to 90) |
| Unused API keys | No API key goes unused for longer than this. | Days |
| Only verified apps | Every connected app (an AI assistant or other OAuth app) is verified. | |
| App scopes limited | Connected apps hold only these permissions. | Scopes, e.g. mcp:read |
| No large exports | No export, download or large listing took more rows than this in the period. | Rows, days to look back |
| Embedding limited | AnyDB may only be embedded in these sites. | Origins |
You can lower any rule's severity to medium or low to separate what must be fixed now from what to review.
What counts as personal data
A share exposes personal data when the record type it shares has:
- a cell marked sensitive, or
- a person cell (user or users) or a signature cell.
AnyDB does not read the content of free-text cells to guess. Mark a cell sensitive when its type is defined to make sure it is counted.
Running a check
Select Check now on a profile. To check a single workspace, choose it in the list next to Check now. You can only pick from the profile's own workspaces. The results list each rule with its answer:
- Fail lists what is at fault, for example the record that is shared publicly or the admin who has been inactive. A failure that the previous check did not find is marked New.
- Cannot check gives the reason. Common reasons:
- Multi-factor sign-in is not a control AnyDB has.
- Sign-ins with no country: country comes from your network's CDN (Cloudflare or CloudFront). A sign-in that arrived without that information cannot be placed in a country, so the rule cannot pass.
- API keys with no recorded use: AnyDB records when an API key was last used starting with this release. Until a key is used again, its age cannot be judged.
Failures are grouped by the workspace to act in. For example, a public share is listed under the workspace that holds the record. Findings that belong to the whole team, such as single sign-on, members, API keys, connected apps and sign-in countries, are listed under Team-wide.
Sign-ins, failed sign-ins and exports are kept for 90 days, so rules that look back are limited to that period.
Past checks and CSV
Every check is kept, the last 50 for each profile.
- Use Past checks to open an earlier one by its date.
- Select Download CSV to save the check shown as a spreadsheet, one row per finding, with these columns:
| Column | What it holds |
|---|---|
| Checked at | When the check ran |
| Profile | The profile's name |
| Rule | The rule's name |
| Severity | high, medium or low |
| Status | pass, fail or cannot_check |
| Workspace, Workspace ID | Where to act, or Team-wide |
| Type, ID, What | What is at fault, for example a share and the record it shares |
| Observed | What AnyDB found |
| New | Whether the previous check found it |
| Reason | Why a rule could not be checked, or how many failures were not listed |
Use the CSV to assign and work through the fixes, then run the check again.
AI Teammates and compliance
An AI Teammate can run your compliance checks, for example on its regular check-in, and alert you when something new fails. To set it up:
- Create the profile in Manage Team → Compliance, or ask the Teammate to propose one and approve it there.
- On the Teammate's Access tab, turn on Can read audit and security data. Only team admins can do this. It lets the Teammate read the whole team's audit and compliance data, not only its own workspaces.
- Give it the job in its check-in instruction, for example: "Every morning, run the ITAR compliance profile. Report the failures in the Operations workspace and the team-wide ones, and alert only on new failures."
To have the Teammate look after one workspace, give the profile that workspace, or have the Teammate check that one workspace. Either way AnyDB filters the findings, not the AI.
A Teammate never changes what is enforced on its own:
- When a Teammate creates a profile, for example when you ask it to "enforce ITAR", the profile is Proposed until a team admin selects Approve.
- When a Teammate changes an existing profile, its change waits as Change proposed. The approved rules stay in force until a team admin approves the change.
From an AI assistant (MCP)
Team admins can manage and run compliance profiles from Claude, ChatGPT or any AI assistant connected through the AnyDB MCP connector, with the same rules and results:
| Tool | Use |
|---|---|
anydb_compliance_catalog | The rule kinds, their values and the starter templates |
anydb_list_compliance_profiles | The team's profiles, with any pending proposal |
anydb_save_compliance_profile | Create a profile (from rules or a template) or change one; workspaces limits what it covers |
anydb_approve_compliance_profile | Approve a proposed profile or change (team admins) |
anydb_delete_compliance_profile | Remove a profile (team admins) |
anydb_check_compliance | Check a profile now (or one workspace with adbid); each failure names its workspace, and the check is kept |
anydb_list_compliance_checks | A profile's kept checks, newest first |
anydb_get_compliance_check | One kept check, in full or as CSV |
Fixing what fails
Compliance checks only report. Fix what they find where you normally would, for example:
- revoke a share from the record's share dialog;
- turn off public sharing in team settings;
- remove a guest from Team Members;
- disconnect an app under Connected apps.
Then run the check again.