Guides
Security policies
Control which domains, API paths, packages and MCP tools your organization's AI agents can use, and redact sensitive data, drafted from chat and switched on by an admin.
Security policies set limits on what Keyboard does on your organization's behalf. Org admins can draft and edit them from their AI client in plain language, then review and switch them on in the Keyboard dashboard.
Policies drafted from chat are always created switched off. Only an admin in the dashboard can switch a policy on, and a policy that's on can only be changed there. Every policy the agent creates or lists comes with a link to review it.
There are two kinds of policy, plus redaction settings.
Code-execution policies
These apply to the code Keyboard runs for your members. Each policy is org-wide or scoped to one team.
| Setting | What it controls | Default for anything unlisted |
|---|---|---|
| Domains | Which hosts code may call, by exact name or with a * wildcard | Deny |
| API path rules | Per host, which methods and paths are allowed or blocked | |
| Packages | Which packages code may install | Allow |
| Binaries | Which programs code may run | Allow |
| Exemptions | Users or teams the policy doesn't apply to |
For each list you can name allowed and denied entries, and choose whether anything on neither list is allowed or denied.
Draft one from chat
- "Create a security policy for the support team that only allows calls to Zendesk, Slack and our help center API."
- "Draft an org-wide policy that blocks any DELETE request to GitHub repositories."
- "Also allow Linear in the support policy."
The agent creates the draft and gives you its dashboard link. Open it, check the rules, tick Policy enabled and save.
Path rules
Path rules give you finer control than domains. Each rule names a method
(or * for any), a path pattern, and whether it's allowed. In a pattern,
* matches one path segment, and a trailing /* matches everything below a
path. For example, a rule on GitHub's API with method DELETE, path
/repos/*/* and allow set to false blocks deleting any repository.
You don't need to write these by hand. Describe the rule and the agent writes it.
MCP server policies
If your organization lets members use other MCP servers through Keyboard, MCP policies decide which of those servers, and which of their tools, members can use.
- Set a default of allow or deny for servers no rule names.
- For each server, allow or deny it entirely.
- For an allowed server, allow all its tools, deny all of them, or list the tools to allow or deny.
Example requests:
- "Create an MCP policy that denies every server except Linear."
- "Draft a policy for the contractors team that allows the Notion server but only its read tools."
The agent looks up the servers your organization has approved before it writes the rules.
Redaction
Redaction removes personal and sensitive data, such as names, emails and phone numbers, from the output of code Keyboard runs before that output is returned to the AI model. Org admins can review and tune it from chat:
- "Show me our redaction settings."
- "Also redact employee IDs. They look like EMP- followed by six digits."
- "Stop redacting our product name, Acme Cloud. It keeps getting flagged."
Changes are merged into your existing settings: entries are added or removed one at a time, and custom patterns are added or updated by name, so an update never wipes out existing rules. If any pattern in an update is invalid, the whole update is rejected.
Two settings can only be changed on the dashboard: turning redaction on or off, and what happens when redaction is unavailable: fail closed (withhold the output) or fail open (return it unredacted).
Who can do this
Only org admins can view, draft or change security policies, and only org admins can change redaction settings. Any member can view the redaction settings.