Security

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

Settings → Security groups four sets of controls: Allowed AI clients, MCP security (newly discovered tools, network access, anomaly detection), personal API tokens, and skill security. 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 Settings → Security → Allowed AI clients.

Airlock recognizes the common clients out of the box — Claude, ChatGPT, Notion, Cursor, and VS Code — 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).

Restricting a client to certain groups. Each row has a group control next to its switch. By default a client is available to everyone ("All groups"). Pick one or more user groups to restrict it — only members of those groups can then connect through that client. Selecting no groups blocks the client for everyone. The on/off switch always wins: a disabled client is refused before group scoping 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.

This is a connect-time control: it stops new connections, but a client that is already connected keeps working until its session ends (up to 30 days).

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:

Both durations are defaults. Under Settings → Security → 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 Security settings:

1. Navigate to Settings → Security and expand the Anomaly detection card (under the MCP security group)
2. Use the switch in the card header to turn anomaly detection on or off for the whole organization
3. Adjust the per-rule thresholds below it (rate spike, repeated denials, error storm, tool enumeration, multi-IP access) — they are dimmed while detection is off

Threshold changes take effect in one direction: raising a threshold makes a rule less sensitive, and that is the supported way to cut false positives for your traffic.

Lowering one does not make detection more sensitive. Detection runs against the built-in defaults and your override is applied afterwards, as a filter that can only discard findings — so the form accepts a lower number and saves it, but nothing extra is ever detected. The same applies to the time-window fields: they are editable and will save, but the built-in windows are what detection actually uses.

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 — 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 (client name, version, transport type, 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 groups rather than individuals to ensure coverage