Security

airlock includes automated security monitoring that detects anomalous API usage patterns and can automatically block suspicious activity.

The Rules page holds Allowed AI clients, newly discovered tools, anomaly detection, and network access. Settings → Security keeps skill security, approvals in AI chat, and personal API tokens. See also the AI Use Policy guide, which covers requiring members to sign your company's AI use policy before their agents can run tools.

Allowed AI clients

You control which AI clients may connect to your organization's MCP endpoint. Open Rules → Allowed AI clients.

airlock recognizes the common clients out of the box (Claude, ChatGPT, Notion, Cursor, VS Code, Microsoft 365 Copilot, and Gemini Enterprise), each with an on/off switch. Turning one off stops that client from completing the MCP sign-in for your organization, for everyone.

Adding your own client. If you run an AI client airlock doesn't recognize, add it with a name and its HTTPS redirect origin. It appears in the same list, starts enabled, and can be switched off later (switching off keeps the entry; removing it deletes it).

When someone tries to connect a client whose callback is not approved, the sign-in error names that callback's origin (for example https://agent.example.com) with a copy button, and tells them an organization admin can add it as a custom client under Rules → Allowed AI clients. Paste that origin into the custom client form. A client that is recognized but turned off gets an error saying so, pointing to the same place to re-enable it.

Restricting a client to certain spaces or people. Each row offers Everyone, Custom or Nobody. By default a client is available to everyone. Choose Custom and name one or more spaces, people, or both: only members of those spaces and the people named can then connect through that client. A person can be named while their invitation is still open; the restriction follows them once they sign in. Naming nobody blocks the client for everyone. The on/off switch always wins: a client set to Nobody is refused before the list is even considered.

Changes are enforced by airlock at sign-in, not by the client. A member who tries to connect through a client that is off, or that they are not scoped to, cannot complete the OAuth flow.

It is checked when a member connects and again every time their session refreshes. A client that is already connected keeps working until its next refresh, so turning a client off, removing it, or changing who may use it takes effect within 8 hours at most.

• Turning a client back on lets its people in again. A session that did not try to refresh while the client was off simply carries on; anyone whose session was refused in that window has to reconnect.
• Removing a custom client also ends every session connected through it, so adding it again later does not bring old sessions back.
• Signing everyone out of one client. Each row has a sign-out icon (Sign out everyone connected through this client). After you confirm with Sign everyone out, everyone currently connected through it loses access at their next refresh, within 8 hours, and has to connect again. The client stays allowed, so they can reconnect straight away. To block the client too, turn it off.

Company workspace only (Claude and ChatGPT)

airlock cannot see which Claude or ChatGPT account a request comes from. A member who signs in to airlock with their company account could still connect airlock to a personal Claude or ChatGPT account. To stop that, give your company workspace its own OAuth client and require it.

1. Under Rules → Allowed AI clients → Company clients, choose Add company client for Claude or ChatGPT, optionally with a name for the workspace it is for. airlock shows the client ID, the client secret and your server URL. The secret is shown once; copy it now.
2. Add airlock to your company workspace with that client:
   • Claude (Team or Enterprise): an Owner adds a custom connector with the server URL and, under Advanced settings, chooses to use their own OAuth client and pastes the client ID and secret.
   • ChatGPT (Business or Enterprise): a workspace admin creates a custom connector with the server URL and enters the client ID and secret in its OAuth settings.
3. Check that members can connect through that connector, then turn on Company workspace only.

From then on airlock refuses that AI client unless it signs in with one of your company's clients. Anyone already connected through a personal account is cut off at their next request and sees why when they try to reconnect. This applies even when Any AI client is selected.

• New secret issues a new secret, and the old one is refused at once. Connectors still on the old secret stop within the hour, when their access runs out, and new sign-ins need the new secret. A connector you update with the new secret before then keeps working. If Claude does not let you edit the connector's sign-in settings, remove it and add it again.
• More than one workspace. If your company has two Claude Enterprise or ChatGPT Enterprise workspaces, add a client for each, up to 10, and paste each into its own workspace. Company workspace only admits all of them.
• Remove deletes that client, and its workspace can no longer connect. Removing the last one also turns Company workspace only off.
• Clients that run on a member's own machine, such as Claude Code, are not covered. For Claude Code, your administrator can pin the organization through Claude Code's managed settings.

Anomaly Detection

airlock continuously scans tool call activity for suspicious patterns. Each rule carries a severity, and the severity decides what happens:

Detection runs automatically every minute. Medium-severity findings are recorded for review but never create a block.

Auto-Blocking

When the anomaly detection system identifies a critical or high finding, it automatically creates a security block. Detection runs every minute, so the calls that trip a threshold have already run; the block applies to the calls after it, usually within a minute or two.

Both durations are defaults. Under Rules → Anomaly detection → Auto-Block Duration you can set each between 1 and 720 hours for your organization. Automatic blocks are always organization-scoped.

• Hard blocks stop the affected user or agent from executing any tool through airlock. The agent can still list and search tools, and Control Room access is unaffected: only tool execution is denied, with the message "Access denied: Your access has been temporarily restricted due to a security review."
• Soft blocks don't deny anything outright: every tool call by the affected user or agent is escalated to Require approval, whatever your policy says, until the block expires or is lifted. Expect a spike in pending requests while a soft block is in force.

Either type can be acknowledged by an admin (to record that it was reviewed) or lifted early if the activity was legitimate. Blocks include details about the finding that triggered them (values, thresholds, detection rule) so admins can assess whether the activity was legitimate.

When detection creates a block automatically (either hard or soft), or upgrades an existing soft block to a hard block, airlock emails all active admins in the organization. The email includes the blocked actor, block type, the reason (with metric values), expiration time, and a link to the Security Blocks dashboard. Extending an existing block does not send anything, so a continuing pattern of activity won't repeatedly email you about a block that is already in force.

Configurable Thresholds

Admins can tune detection sensitivity per organization from the Rules page:

1. Navigate to Rules and expand the Anomaly detection card (under the Limits and records group)
2. Use the switch in the card header to turn anomaly detection on or off for the whole organization
3. Adjust each rule's threshold and time window below it (rate spike, repeated denials, error storm, tool enumeration, multi-IP access, escalation probing). They are dimmed while detection is off

Each rule's threshold and time window apply in both directions. Lower a threshold or widen a window to make a rule more sensitive; raise a threshold or narrow a window to cut false positives for your traffic. A more sensitive rule also raises more automatic blocks when it is a rule that blocks. The value shown in each field is the one detection uses, and the next detection run (once a minute) picks up a saved change.

Every field has an allowed range, shown when you hover over it:

Escalation probing has a time window but no threshold: it looks for a fixed mix of allowed and denied calls.

If a rule is noisy and raising its threshold isn't enough, turn detection off with the master toggle. When detection is disabled, airlock stops creating new anomaly findings and automatic blocks for that organization.

Security Blocks Dashboard

View and manage security blocks from the Control Room:

1. Navigate to Security in the sidebar
2. View active, acknowledged, and expired blocks
3. Each block shows:
   • The affected user
   • The detection rule that triggered it
   • Finding details (values vs. thresholds)
   • Block status and expiration time

Managing Blocks

• Acknowledge a block (hard or soft) to indicate you've reviewed it
• Lift a block early if the activity was legitimate
• Blocks stop applying the moment they reach their expiry time (4 and 24 hours by default, or whatever you configured)

Creating a block manually

Admins can also block someone directly, without waiting for detection. On the Security page choose Create block, then pick the user, whether it's a hard or soft block, how long it lasts (1–720 hours), and its scope:

• Organization: applies to every integration in the org.
• Project: applies only to the integration you select; the user's other integrations keep working.

Manually created blocks are acknowledged, lifted, and expired exactly like automatic ones. They do not send the admin notification described under Auto-Blocking, since you already know about a block you created yourself.

Credential Security

All API credentials are protected with defense-in-depth:

• KMS envelope encryption: every stored credential is encrypted with its own unique AES-256-GCM data key, and that data key is itself wrapped by an airlock-managed AWS KMS key. There is no standalone master key that could leak; unwrapping data keys always goes through KMS.
• Per-record isolation: decryption is cryptographically bound to the owning organization and record (via the KMS encryption context), so a credential can never be decrypted outside the organization and record it belongs to
• Runtime-only decryption: credentials are decrypted only when making API calls, never logged
• Organization isolation: every stored record carries the owning organization's identifiers, and every read and write is scoped against the caller's server-side profile. Role decisions (admin vs. member) are made from that stored profile, never from a claim in the caller's token, so a stale or over-broad token cannot widen access

Audit Trail

All API calls, approval decisions, and security events are logged with:

• Who made the request (user and agent identity)
• What tool was called and with what parameters
• When the request was made
• The policy decision (allowed, required approval, blocked)
• Agent context (the AI client, shown by product name with the version it reported, plus transport type and source IP)

Audit logs are accessible from the Control Room under History.

Best Practices

1. Monitor the Security dashboard regularly for blocks and findings
2. Review acknowledged blocks to identify patterns in false positives
3. Use approval workflows for sensitive operations as an additional layer of protection
4. Rotate credentials periodically and revoke unused access
5. Assign approver spaces rather than individuals to ensure coverage