> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guardway.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Claude Connector
> Manage your organization's gateway API keys, policies, members, alerts and anomalies, providers and MCP servers, and read its usage, spend, audit log, effective policy, AI use on its machines and AI inventory, from Claude — claude.ai, Claude Desktop or Claude Code — with your own Guardway role.
## What this is for
The **Guardway connector for Claude** lets Owners and Admins manage the organization's gateway [API keys](/platform/configuration/api-keys) by asking Claude: find keys, create one with the right restrictions, tighten or loosen what a key can reach, rotate it or revoke it. Owners and Admins can also change the organization's policies and guardrail rules (block a model for an application, add banned keywords, turn on PII redaction), switch MCP tools on and off, invite and remove members, act on anomalies and alert rules, and add providers and MCP servers. Anyone in the organization can also ask Claude about usage and spend, guardrail and MCP activity, the audit log, members, anomalies, gateway health and what policy an application actually gets, and about AI use across the company: who uses which AI tools on which machines, and which repositories and cloud agents use AI. Claude sees metadata about people's AI use, never what they typed. It works in claude.ai, Claude Desktop and Claude Code, and it is available to every Guardway organization.
Claude acts as **you**, with your current role in each organization. Read Only members can connect too, but can only look.
The connector server URL is:
```
https://mcp.guardway.ai/mcp
```
## Options
### What Claude can do
| Tool | What it does |
| - | - |
| `whoami` | Shows who you are signed in as, your organizations and your role in each. |
| `list_api_keys` | Lists the organization's gateway API keys with a short summary of each, optionally filtered by name or owner. Expired keys are hidden unless you ask for them. |
| `get_api_key` | Shows one key in full: models, MCP servers and tools, rate limits, budget, expiry, owner, and its recent usage. |
| `create_api_key` | Creates a key with restrictions: allowed models, MCP servers and tools, rate limits, budget and budget alerts, expiry, owner, team and application. |
| `update_api_key` | Changes a key's restrictions and shows a before/after of what changed. |
| `rotate_api_key` | Replaces a key's secret. Always asks you to approve a preview first. |
| `revoke_api_key` | Deletes a key. Always asks you to approve a preview first. |
Besides keys, the connector changes policies and guardrail rules, MCP tool switches, members and invitations, anomalies and alert rules, and providers and MCP servers, reads AI use on your machines and your AI inventory, and refreshes cloud agent discovery (see the sections below). Gateways, applications, webhooks, guardrail settings, password resets and every other setting stay in the dashboard, and nothing is deleted from the chat.
### Reading usage, the audit log and policies
| Tool | What it does |
| - | - |
| `get_usage_report` | Usage and spend for a period, grouped by model, provider, key, user, team or day: requests, tokens, cost and blocked requests. |
| `get_security_activity` | Guardrail triggers and MCP tool calls: which guardrails fired most, and which MCP tools were called. |
| `search_audit_log` | Searches the [Audit Log](/platform/settings/audit-log): who did what, and when — keys, policies, MCP servers, providers, members, roles and API tokens. |
| `get_policy_posture` | A summary of the organization's protection: guardrail policies, unified policies, applications, MCP tools and providers. |
| `get_policy` | One guardrail policy, unified policy, application, MCP tool or provider in detail. |
**These tools are read-only.** They can't change anything. Policies and guardrail rules are changed with the tools in [Changing policies and guardrail rules](#changing-policies-and-guardrail-rules); members, alert rules, providers and MCP servers have their own tools below. Provider credentials and other secrets are never returned.
**Cost can be understated.** A request the gateway couldn't price — for example, a model called by an Azure deployment name that has no price — counts as \$0. When that happens, Claude says how many requests had no price, so treat the total as a lower bound.
* **Usage lags by about an hour.** Usage and spend come from hourly rollups, so the most recent hour may be missing. Claude says how far behind real time the figures are.
* **Rows don't always add up.** Grouped by key, user or team, traffic that isn't attributed to one shows up in the totals only. MCP traffic has no model and shows as "MCP traffic (no model)".
### Changing policies and guardrail rules
Owners and Admins can change the organization's policies and guardrail rules by asking Claude. A **policy** applies to all traffic in the organization (the baseline) or to one application (an override), and sets which models, providers and MCP servers and tools are allowed or denied, plus Safety SLM, prompt injection, rate limits, budget and detection. A **guardrail rule** inspects traffic: banned keywords and patterns, PII, content filter, prompt injection, topics. See [Security](/platform/configuration/security) for what each one does.
| Tool | What it does |
| - | - |
| `create_policy` | Creates a policy for a scope that has none yet: the organization baseline or one application. Always asks you to approve a preview first. |
| `update_policy` | Changes a policy: add or remove denied and allowed models, providers, MCP servers and tools, change a section's settings, or turn the policy on or off. |
| `create_guardrail_rule` | Creates a guardrail rule — keyword, PII, content filter, prompt injection, topic and more — for every application or for one. |
| `update_guardrail_rule` | Changes a guardrail rule: its name, whether it's on, its action, what it applies to (requests, responses or both), its keywords, patterns or categories, exceptions and thresholds. |
Example prompts:
* "Block GPT-4o for the support app"
* "Add 'project falcon' to the banned keywords rule"
* "Turn on PII redaction for responses"
* "Allow the GitHub MCP server's read tools for the checkout app"
#### Claude asks before weakening protection
A change that adds protection is applied at once: denying a model, adding banned keywords, turning a rule on, switching a rule from warn to block. A change that **weakens** protection is never applied directly.
Claude judges a policy change by its effect on the [effective policy](#effective-policy-and-mcp-tools): what traffic gets once the organization baseline and the application's policy are combined, on every gateway the change reaches. If protection gets weaker anywhere, Claude asks first. Claude first shows you a preview, and nothing changes until you approve it in the conversation. Weakening changes include:
* turning a policy, a section or a guardrail rule off;
* allowing every MCP server (an empty allow list means everything is allowed), or allowing more MCP tools;
* moving a rule's action from block to warn, or to a weaker action;
* removing a denied model, server or tool, or removing keywords, patterns or categories from a rule;
* clearing a policy section;
* raising a rate limit, budget or threshold, adding exceptions, or narrowing what a rule applies to.
Creating a policy is judged the same way: a new application policy that only adds protection on top of the baseline is applied at once, and one that allows something the baseline denies asks first. Turning an application's policy on or off is weighed against the baseline it falls back to. A setting Claude doesn't recognize is treated as weakening.
The preview shows:
* the policy or rule and the scope it affects — for example, "all traffic in the organization" for the baseline, or one application;
* a one-line explanation of each thing that gets weaker;
* the full change, before and after;
* when the change takes effect.
A preview expires after 5 minutes, and it is refused if someone changes the policy or rule in the meantime — or, for an application's policy, the baseline it builds on: ask Claude again for a fresh preview.
#### No deletes from chat
Claude can't delete a policy or a guardrail rule. If you ask it to, it offers to turn it off instead, which is a weakening change and so needs your approval. Deleting is done in the dashboard.
#### Good to know
* **Changes aren't instant.** Gateways pick a change up on their next config refresh, usually within a minute.
* **Owners and Admins only.** Read Only members can read policies but not change them. A Claude Code token also needs **Read and change policies & guardrail rules** access (see [Token scopes](#token-scopes-for-claude-code)).
* **Credentials stay out of the chat.** The endpoint URLs and credentials of a guardrail rule that uses an SLM classifier are never shown or changed through Claude.
* **Applications** are still added and edited in the dashboard. Providers and MCP servers have their own tools: see [Connections](#connections-providers-and-mcp-servers).
### Team
Anyone in the organization can ask who's in it. Owners and Admins can also invite people, change roles and remove members, as on [Users](/platform/settings/members).
| Tool | What it does |
| - | - |
| `list_members` | Lists members with their role, status, when they joined and when they last signed in, plus pending invitations and when they expire. |
| `invite_member` | Invites one email address as **Admin** or **Read Only**. If that address already has a pending invitation, it is sent again. Always asks you to approve a preview first. |
| `change_member_role` | Moves a member between **Admin** and **Read Only**. Changing an Admin to Read Only is applied at once; making someone an Admin asks you to approve a preview first. |
| `remove_member` | Removes someone from the organization. Always asks you to approve a preview first. |
| `revoke_invitation` | Cancels a pending invitation. |
| `resend_invitation` | Sends a pending invitation again. |
Example prompts:
* "Who in our org is an Admin?"
* "Which invitations are still pending?"
* "Invite [dana@example.com](mailto:dana@example.com) as Read Only"
* "Make Bob read-only"
* "Remove [alice@example.com](mailto:alice@example.com) from the org"
#### Good to know
* **What the previews show.** An invite names the email, the role and what that role can do, the organization, and that an invitation email will be sent. A removal says what happens to the person's access: the API tokens they created are revoked, and their access on your gateways drops to read-only. Gateway API keys they own are **not** revoked; revoke or reassign them separately.
* **Only addresses you typed.** Claude invites only an email address you give it in the conversation, never one it read in a tool result, such as an audit log entry or a policy name.
* **Someone who already joined.** An invitation can be revoked or re-sent only while it is pending. Once the person has joined, Claude says so and offers to remove them as a member instead, which asks you first.
* **What only the Owner can do.** Promoting a member to **Admin**, and inviting someone as **Admin** through Claude, need the Owner; an Admin's request is refused before any preview. Nobody can change or remove the Owner, or change or remove themselves, from Claude.
* **Password resets stay in the dashboard.** Claude can't send a password reset or transfer ownership.
### Operations
Anyone in the organization can ask about anomalies, alert rules and gateway health. Owners and Admins can also act on anomalies and manage alert rules. An anomaly is raised when an API key's behavior on a gateway drifts from what the gateway learned is normal for it, which is often the first sign of a stolen or misused key (see the **Anomalies** tab of [Security](/platform/configuration/security)). Alert rules are the ones in [Notifications](/platform/settings/notifications).
| Tool | What it does |
| - | - |
| `list_anomalies` | Lists anomalies, filtered by status, severity, key or time. |
| `get_anomaly` | One anomaly in detail: its timeline, what the gateway did, and the key's current name and owner and whether it still exists. |
| `acknowledge_anomaly` | Marks an anomaly as seen and stops repeat alerts for it. It stays open. |
| `resolve_anomaly` | Closes an anomaly. The key's learned baseline is kept, so the same drift alerts again. |
| `rebaseline_anomaly` | Tells the gateway to re-learn what's normal for the key from its current traffic. Always asks you to approve a preview first. |
| `list_alert_rules` | Lists alert rules with their condition, threshold, severity, cooldown and where they notify, optionally with recent deliveries. |
| `create_alert_rule` | Creates an alert rule that notifies a webhook or a Slack channel your organization already uses. |
| `update_alert_rule` | Changes an alert rule. A change that makes it alert less asks you to approve a preview first. |
| `test_alert_rule` | Sends a test alert for a rule. This delivers a real message to its destination. |
| `get_gateway_health` | Lists gateways that haven't checked in recently (10 minutes by default), run an outdated version or a version with a security update, or are behind on configuration. |
| `get_config_history` | When the gateway configuration changed, and to which version. Ask about the [Audit Log](/platform/settings/audit-log) for who changed it. |
Example prompts:
* "Any open high-severity anomalies this week?"
* "What's going on with the anomaly on the checkout-service key?"
* "Acknowledge that anomaly, we're looking into it"
* "Alert the #security Slack channel when requests get blocked"
* "Which gateways are out of date?"
#### Good to know
* **Rebaselining asks first.** Rebaselining declares the key's new behavior normal, which would hide a stolen key. The preview says so and suggests rotating the key instead. If you ask Claude to deal with a key that's "acting weird", it offers to rotate it, not to rebaseline.
* **Alerting less asks first.** For an alert rule, these changes ask you to approve a preview: turning it off, changing its condition, raising its threshold, lowering its severity, lengthening its cooldown, or removing or moving a destination. Adding a rule, turning one on and the opposite changes are applied at once.
* **Destinations.** A new alert rule notifies a webhook or a Slack channel that an existing rule already uses, or one you pick in the dashboard. Claude doesn't create webhooks, and PagerDuty, Opsgenie and Microsoft Teams channels are shown by type only and set up in the dashboard: they hold credentials.
* **Alert rules aren't deleted from chat.** Claude offers to turn a rule off instead, which asks first.
### Effective policy and MCP tools
An application's traffic is governed by the organization baseline plus that application's own policy, and a policy can be pinned to one gateway. Claude can show what an application actually gets once these are combined, and which policy set each setting. Owners and Admins can also switch discovered MCP tools on and off.
| Tool | What it does |
| - | - |
| `get_effective_policy` | The policy that applies to an application, a gateway or both, after the baseline and overrides are combined. Each setting names the policy that set it. For an application on more than one gateway, it shows where gateways differ. |
| `list_mcp_servers` | Lists MCP servers: name, type, whether each is on, health, gateways, and how many of its tools are on. Connection details are never shown. |
| `get_guardrails_config` | The organization's guardrail settings: the enforcement mode and whether each guardrail is on. Credentials show only as set or not set. |
| `set_mcp_tool_enabled` | Switches up to 50 tools of one MCP server on or off for the whole organization, on every gateway. Switching tools off is applied at once; switching them on asks you to approve a preview first. |
Example prompts:
* "What policy does the support app actually get?"
* "Why is GPT-4o blocked for checkout?"
* "Which tools on the jira server are switched off?"
* "Turn off delete\_repository on the github MCP server"
`get_effective_policy`, `list_mcp_servers` and `get_guardrails_config` are read-only and open to every role. Switching a tool off for everyone is different from denying it in a policy: to allow or deny a tool for one application, ask Claude to change that application's policy (see [Changing policies and guardrail rules](#changing-policies-and-guardrail-rules)). Guardrail settings themselves are still changed in the dashboard.
### Connections: providers and MCP servers
Anyone in the organization can list providers and MCP servers. Owners and Admins can also add and change them. Credentials are never typed in the chat: Claude gives you a one-time link to enter them in Guardway (see [Secrets never go through Claude](#secrets-never-go-through-claude)).
| Tool | What it does |
| - | - |
| `list_providers` | Lists [providers](/platform/configuration/providers): type, status, gateway, the host requests go to, enabled models, and whether a credential is stored. |
| `get_provider` | One provider in detail, including its last health check. Credential values are never shown. |
| `create_provider` | Adds a provider with no credential yet, then gives you a link to enter it. |
| `update_provider` | Turns a provider on or off, adds or removes models, or changes its endpoint URL, API version or display name. |
| `request_provider_secret` | Gives you a new link to replace a provider's key, for example to rotate it or after a link expired. |
| `create_mcp_server` | Registers an [MCP server](/platform/configuration/mcp), switched off, then gives you a link for its credentials. |
| `update_mcp_server` | Turns an MCP server on or off, renames it, or changes its description, URL, command or arguments. |
| `request_mcp_server_secret` | Gives you a new link to replace an MCP server's headers, environment variables or OAuth client secret. |
| `discover_mcp_tools` | Asks the gateway to list an MCP server's tools, and shows their names and whether each is on. |
Example prompts:
* "Add an Anthropic provider on the prod gateway with claude-sonnet"
* "Rotate the OpenAI key"
* "Disable gpt-4o on the azure provider"
* "Register our docs MCP server at [https://mcp.example.com/mcp](https://mcp.example.com/mcp)"
* "Which tools does the jira server have?"
#### Good to know
* **A new provider waits for its key.** It shows as **Waiting for credentials** in the dashboard and isn't sent to your gateways until the key is saved through the link. Claude tells you which host the key will be sent to, so you can check it before you type the key.
* **A new MCP server starts switched off.** Turning it on asks you first. A server that signs in with OAuth gets a link to the dashboard to sign in, as described in [Sign in to a server (OAuth)](/platform/configuration/mcp#sign-in-to-a-server-oauth).
* **Widening access asks first.** Turning a provider back on, adding models to it, changing its endpoint URL (which redirects every request and its stored key), turning an MCP server on, and changing an MCP server's URL, command or arguments all ask you to approve a preview first. Turning things off and removing models are applied at once. Claude won't remove a provider's last model: turn the provider off instead.
* **AWS Bedrock.** The access key ID is an identifier, not a secret, so you can give it to Claude. The secret access key (and a session token, for temporary credentials) goes through the link.
* **No deletes from chat.** Claude can't delete a provider or an MCP server. It offers to turn it off instead. Deleting is done in the dashboard.
* **Changes aren't instant.** Gateways pick up provider and MCP server changes, and MCP tool switches, on their next config refresh, usually within a minute.
### Endpoints and people
Anyone in the organization can ask about AI use on the company's laptops and workstations: the machines that report to Guardway through the [Guardway CLI](/discovery/guardway-cli/overview), the people who use them, the AI tools and accounts they use, and their AI coding sessions. These tools are read-only, and they return **metadata only**: Claude never sees prompt or response text (see [What Claude sees about people's AI use](#what-claude-sees-about-peoples-ai-use)).
| Tool | What it does |
| - | - |
| `get_ai_fleet_overview` | One overview of AI on your machines: how many are enrolled, active and stale, which AI tools people use, personal and corporate AI accounts, risk bands and the machines whose risk changed most. |
| `list_people` | Lists the people using AI on your machines: their machines, AI tools, signed-in AI accounts (corporate or personal), risk and 30-day AI request counts. Filter by AI tool, personal accounts only, minimum risk or name. |
| `get_person` | One person in detail: machines, AI tools and accounts, risk, counts of sensitive data in their prompts over 30 days (secrets, PII, source code; counts only), and their gateway spend over 30 days. |
| `list_endpoints` | Lists reporting machines: hostname, OS username, OS, agent version, last report, whether it's stale, risk band and AI account counts. Filter by stale only, OS, minimum risk, user or hostname. |
| `get_endpoint` | One machine in detail: what's installed (AI tools, agents, skills, MCP servers, extensions), its AI accounts, risk, its latest AI requests and its AI sessions. |
| `list_ai_sessions` | A person's or a machine's Claude Code and Cursor sessions, newest first: when each ran, how many prompts (typed by the person or sent by agents), subagents, models, tokens and sensitive-data counts. |
| `get_ai_session` | One session's timeline: the main thread and its subagents, when each prompt was sent and by whom, and each response's model, tokens and the names of the tools it called. |
| `get_shadow_ai_report` | Unsanctioned AI: people signed in to AI tools with personal accounts, AI tools used only with personal accounts, machines whose AI traffic bypasses Guardway, and custom model endpoints. |
Example prompts:
* "Who in the company uses AI tools with personal accounts?"
* "Which machines haven't reported in a week?"
* "What AI tools does Dana use, and how much did she spend through the gateway this month?"
* "Show Bob's Claude Code sessions this week"
* "Give me a shadow AI report"
#### Good to know
* **Never prompt or response text.** Asked "what did Bob ask Claude?", Claude answers with the session's metadata (when, which tool, how many prompts, models, tools called) and says the text is only in the dashboard **People** view, for Owners and Admins. It doesn't guess what was asked from tool names or counts.
* **AI accounts by domain.** A signed-in AI account shows its tool, whether it's corporate or personal, its plan and its email domain (for example gmail.com), never the address.
* **No IP addresses.** Machines are shown by hostname and OS username. IP addresses are never shown.
* **Names come from the machines.** Usernames, hostnames and AI tool names are reported by each machine. Claude treats them as data and quotes them; it doesn't follow instructions written in them.
* **Organization-wide spend** by user, key or team stays with `get_usage_report` (see [Reading usage, the audit log and policies](#reading-usage-the-audit-log-and-policies)).
### Discovery and AI inventory
Anyone in the organization can ask what AI is in your code and your cloud accounts: the repositories of your connected GitHub organizations that use AI (see [Repositories](/discovery/repositories)), and the Azure AI Foundry and Amazon Bedrock agents found in your cloud accounts with their OWASP Agentic Top 10 findings (see [Agents](/platform/agents)). Owners and Admins can also refresh the cloud agent inventory.
| Tool | What it does |
| - | - |
| `get_ai_inventory_summary` | One view of your AI inventory: repositories using AI and the providers, SDKs and MCP servers found in their code, cloud agents by provider and model, agent findings by severity and OWASP category, and the health of your discovery connections (GitHub, Slack, Azure, AWS). |
| `list_ai_repos` | Lists repositories that use AI, from each one's latest scan: the providers, AI SDKs, MCP servers and AI gateways found, and when it was last scanned. Filter by provider, finding type or GitHub organization. |
| `get_repo_ai_findings` | One repository's AI findings (file, provider, package and version) and its AI bill of materials, with a link to its page in the dashboard. |
| `list_cloud_agents` | Lists cloud agents: provider, account, models, tools and MCP servers, whether traffic goes through the Guardway gateway, and finding counts. Filter by provider, model, name, gateway routing or agents with findings. |
| `get_cloud_agent` | One cloud agent in detail: models, tools, MCP servers, gateway routing, its Entra ID identities (display names, credential health, risky scopes) and its findings. |
| `list_agent_findings` | Lists OWASP Agentic Top 10 findings (ASI01–ASI10) on your cloud agents: severity, category, rule, the agent, a summary of the evidence and the remediation. Filter by minimum severity, category, provider or agent. |
| `refresh_cloud_agents` | Re-reads the agents from your Azure and AWS accounts now, for every connected account or one provider. Results land within a few minutes. |
Example prompts:
* "What AI do we have?"
* "Which repos use OpenAI?"
* "Show the AI bill of materials for acme/api"
* "What AI agents run in our cloud, and which bypass the gateway?"
* "What are our critical agent findings?"
* "Refresh our Azure agents"
#### Good to know
* **System prompts are never shown.** Claude sees whether a cloud agent has instructions and how long they are, never their text.
* **Refreshing runs once, with a cooldown.** `refresh_cloud_agents` is applied directly, without a preview: it only adds visibility. It calls your cloud providers' APIs with the credentials stored in Guardway. Each connection refreshes one at a time and then has a cooldown of about 15 minutes. If a refresh is already running, or the connection refreshed recently, Claude says so and when you can refresh again, instead of retrying. Refreshing needs the Owner or Admin role.
* **Repositories are read-only from Claude.** Claude can't scan or re-scan a repository. Asked to, it points you to the **Scan** button on the repository in the dashboard (see [Repositories](/discovery/repositories)).
* **Credentials stay hidden.** A discovery connection shows its provider, account name, status and last sync, never its credentials or configuration.
* **Names come from your code and cloud.** Repository names, file paths, agent and tool names and finding text can be written by anyone who can push to a repository or create an agent. Claude treats them as data and doesn't follow instructions written in them.
### Example prompts
* "Which API keys can use every model and have no budget?"
* "Create a key for the support bot limited to claude-sonnet with a \$50 monthly budget that expires in 90 days."
* "Only let the `checkout-service` key call `search_code` and `list_pull_requests` on the github MCP server."
* "Who owns the keys that haven't been used in the last 30 days?"
* "Rotate the checkout-service key."
* "Revoke all expired keys owned by [alice@example.com](mailto:alice@example.com)."
* "Who spent the most this week?"
* "Cost by model for the last 30 days."
* "What changed in our org yesterday?"
* "Is PII redaction on?"
* "Which guardrails fired most?"
## How to configure
claude.ai and Claude Desktop sign in to Guardway with your own Guardway account. There is no token to copy.
In Claude, open **Settings → Connectors** and choose **Add custom connector**. Enter the server URL `https://mcp.guardway.ai/mcp`.
Open **Advanced settings** and set **OAuth Client ID** to:
```
651919d4-7446-4915-9b77-da4337716e3c
```
Leave the client secret empty.
Choose **Connect**. Claude opens Guardway; sign in with the account you use for the dashboard.
The consent screen reads **Connect Claude to Guardway**. Check that it says you'll be sent back to **claude.ai** after you approve, and that **Signed in as** shows the right account (use **Switch account** if not). Choose **Approve**.
Depending on your Claude plan, an owner may need to add the connector for your Claude organization first. Each person then connects and signs in with their own Guardway account.
Claude Code connects with a Guardway API token instead of signing in.
In the dashboard, open **Settings → API tokens** and choose **Create token**. Give it a **Name** and pick its access. Under **API keys**, choose **Read and manage API keys** to make changes, **Read API keys** to only look, or **No access to API keys**. Under **Reports (read-only)**, tick the reports Claude may read: **Usage & spend (read)** and **Audit log (read)**. Under **Policies**, choose **Read and change policies & guardrail rules** to let Claude change them, **Read policies & posture** to only look, or **No access to policies**. **Members**, **Operations (alerts & anomalies)** and **Connections (providers & MCP servers)** are chosen the same way: no access, read, or read and change (see [Token scopes](#token-scopes-for-claude-code)). Under **Endpoints & people**, choose **Read endpoints & people** or **No access to endpoints & people**. Under **Discovery**, choose **Read and refresh discovery** to let Claude refresh cloud agents, **Read discovery** to only look, or **No access to discovery**. Pick a **Lifetime** of 7, 14 or 30 days. Copy the token: this is the only time it is shown.
```bash theme={null}
claude mcp add --transport http guardway https://mcp.guardway.ai/mcp \
--header "Authorization: Bearer YOUR_API_TOKEN_HERE"
```
Run `/mcp` in Claude Code. `guardway` shows as connected. Ask "What can this token do?" and Claude lists what the token's scopes allow.
Only Owners and Admins can create API tokens. A token acts as the member who created it, with that member's current role, and expires after its lifetime. Rotate or revoke it in **Settings → API tokens**.
Then ask Claude something like "Which Guardway organization am I connected to?" to confirm.
## Permissions
* **Your role, checked on every call.** Owners and Admins can create, change, rotate and revoke keys. Read Only members can only list and inspect them. A role change applies on the next call.
* **Reading** usage, the audit log, policies, members, anomalies, alert rules, gateway health, providers and MCP servers, endpoints and people, and the AI inventory is open to every role, Read Only included.
* **Changing policies and guardrail rules**, switching MCP tools, managing members, acting on anomalies and alert rules, adding or changing providers and MCP servers, and refreshing cloud agents need the Owner or Admin role. Read Only members can read all of these but change none of them. Deleting is done in the dashboard only.
* **Some team changes need the Owner.** Promoting a member to Admin, and inviting someone as Admin through Claude, are refused for Admins. Nobody can change or remove the Owner, or themselves, from Claude.
* **Claude Code tokens** are also limited by their scopes: a **Read API keys** token can't change anything, whatever your role, and a token without **Usage & spend (read)** can't read usage.
* **Several organizations.** If you belong to more than one, Claude asks which organization to work in. Tell it by name.
### Token scopes for Claude Code
Each tool needs a scope on the token. **Usage & spend** and **Audit log** are independent: pick either, both or neither. **Policies**, **Members**, **Operations (alerts & anomalies)**, **Connections (providers & MCP servers)**, **Endpoints & people** and **Discovery** are one level each, chosen like API key access; read and change (or read and refresh) always includes read. **Endpoints & people** has no change level.
| Access in the dashboard | Scope | Tools it allows |
| - | - | - |
| **Read API keys** | `keys:read` | `list_api_keys`, `get_api_key` |
| **Read and manage API keys** | `keys:write` (includes `keys:read`) | the two above, plus `create_api_key`, `update_api_key`, `rotate_api_key`, `revoke_api_key` |
| **Usage & spend (read)** | `usage:read` | `get_usage_report`, `get_security_activity` |
| **Audit log (read)** | `audit:read` | `search_audit_log` |
| **Read policies & posture** | `policies:read` | `get_policy_posture`, `get_policy`, `get_effective_policy`, `list_mcp_servers`, `get_guardrails_config` |
| **Read and change policies & guardrail rules** | `policies:write` (includes `policies:read`) | the read tools above, plus `create_policy`, `update_policy`, `create_guardrail_rule`, `update_guardrail_rule`, `set_mcp_tool_enabled` |
| **Read members & invitations** | `members:read` | `list_members` |
| **Read and manage members & invitations** | `members:write` (includes `members:read`) | `list_members`, plus `invite_member`, `change_member_role`, `remove_member`, `revoke_invitation`, `resend_invitation` |
| **Read alerts, anomalies & gateway health** | `ops:read` | `list_anomalies`, `get_anomaly`, `list_alert_rules`, `get_gateway_health`, `get_config_history` |
| **Read and act on alerts & anomalies** | `ops:write` (includes `ops:read`) | the read tools above, plus `acknowledge_anomaly`, `resolve_anomaly`, `rebaseline_anomaly`, `create_alert_rule`, `update_alert_rule`, `test_alert_rule` |
| **Read providers & MCP servers** | `connections:read` | `list_providers`, `get_provider`, `list_mcp_servers` |
| **Read and change providers & MCP servers** | `connections:write` (includes `connections:read`) | the read tools above, plus `create_provider`, `update_provider`, `request_provider_secret`, `create_mcp_server`, `update_mcp_server`, `request_mcp_server_secret`, `discover_mcp_tools` |
| **Read endpoints & people** | `endpoints:read` | `get_ai_fleet_overview`, `list_people`, `get_person`, `list_endpoints`, `get_endpoint`, `list_ai_sessions`, `get_ai_session`, `get_shadow_ai_report` |
| **Read discovery** | `discovery:read` | `get_ai_inventory_summary`, `list_ai_repos`, `get_repo_ai_findings`, `list_cloud_agents`, `get_cloud_agent`, `list_agent_findings` |
| **Read and refresh discovery** | `discovery:write` (includes `discovery:read`) | the read tools above, plus `refresh_cloud_agents` (which also needs the Owner or Admin role) |
`whoami` works with any token, and lists what the token can do in each area. A token with **Read providers & MCP servers** but not **Read policies & posture** sees MCP servers, and the tools it discovers, without tool names. Password resets are never open to a token, and no token can scan a repository. When Claude checks your organization's setup, it sees how many machines are enrolled and reporting, as counts only: who uses them and their hostnames need **Read endpoints & people**, and IP addresses are never shown.
claude.ai and Claude Desktop have no token scopes: they can use every tool, and what they can do follows your role. A Read Only member can only read, and the Owner-only team changes above still need the Owner.
## How your keys stay safe
* **Key secrets never appear in the chat.** When Claude creates or rotates a key, you get a one-time link instead. Open it in your browser while signed in to Guardway to see the key. The link works once, only for you, and for 10 minutes.
* **Destructive changes need your approval.** Rotating a key, revoking a key, and any change that removes a restriction (for example, removing a budget or an expiry, or letting a key use every model) always show you a preview first: the key's name, owner, expiry, last use and what will happen. Nothing changes until you approve in the conversation. A preview expires after 5 minutes, and it is refused if someone changes the key in the meantime.
* **No gateway-admin access.** The connector can't give a key gateway-admin access, and can't rotate or edit a key that already has it. Do that in the dashboard.
* **Weakening protection or granting access needs your approval too.** Claude shows a preview and waits for you before it weakens a policy or guardrail rule, switches MCP tools on, invites, promotes or removes a member, rebaselines an anomaly, makes an alert rule alert less, or turns on or widens a provider or an MCP server. See [Claude asks before weakening protection](#claude-asks-before-weakening-protection).
* **Every change is audited.** Each key create, edit, rotate and revoke, and each change Claude makes to policies, rules, MCP tools, members, alert rules, providers and MCP servers, is recorded in the [Audit Log](/platform/settings/audit-log) under your name, noting that it came through the connector.
## Secrets never go through Claude
Provider keys and MCP server credentials go into Guardway through a **one-time link**, never through the chat. When Claude adds a provider or an MCP server, or you ask it to replace a credential, it creates a link and gives it to you:
Open it in your browser while signed in to the Guardway dashboard, in the same organization. It opens a page under `/secrets/input/` in the dashboard that reads **Claude asked you to enter** the fields it needs, **for** the provider or MCP server by name. Opening the page doesn't use the link up.
Type each value into its masked field and choose **Save**. The values go straight to Guardway, encrypted, and Claude never sees them. Saving replaces any value already stored for those fields.
The page reads **Saved. You can return to Claude.** A provider that was waiting for its key becomes active, and your gateways pick it up on their next config refresh.
* **One use, 10 minutes, only you.** A link saves values once and expires 10 minutes after Claude creates it. Only the member who asked Claude for it can open it; for anyone else, or in another organization, it reads **Link not found**.
* **An expired or used link** reads **This link has expired** or **This link was already used**. Ask Claude for a new link.
* **Claude refuses a secret pasted in the chat.** If you paste a key into the chat, Claude won't pass it to Guardway: a request carrying anything that looks like a key, token, password or private key is refused before anything is sent, without repeating the value, and Claude offers a link instead. The value is still in your chat history, so **rotate it** with the provider or MCP server, then enter the new one through a link.
* **Credentials stay hidden on the way out too.** Providers and MCP servers are shown with credentials masked or as "stored", never as values.
## What Claude sees about people's AI use
**Claude never sees what people typed into AI tools, or what the tools answered.** Guardway removes prompt and response text before anything reaches the connector, and the connector removes it again on its own, so a gap in one still leaves none in the chat.
* **What Claude sees:** who uses which AI tools on which machines, whether their AI accounts are corporate or personal (by email domain), risk, counts of sensitive data found in prompts (secrets, PII, source code), and session timelines: when, which tool, which models, token counts and the names of the tools an AI session called.
* **What Claude never sees:** prompt or response text, what a subagent was asked to do, the email address of a signed-in AI account, IP addresses, or the system prompt of a cloud agent.
* **Where the text is.** Owners and Admins can read prompt text in the dashboard **People** view. Ask Claude about a person and it points you there when you need the words, not just the metadata.
* **Who can ask.** Every role can read this metadata through Claude, Read Only included. A Claude Code token needs **Read endpoints & people**.
## Disconnect
* **claude.ai and Claude Desktop:** in Guardway, open **Settings → Account → Connected apps** and choose **Disconnect** next to Claude. Access stops immediately. You can also remove the connector in Claude.
* **Claude Code:** revoke the token in **Settings → API tokens**, or run `claude mcp remove guardway`. Tokens also stop working when they expire, after at most 30 days.
## Troubleshooting
You signed in with an account that has no Guardway organization. Ask an Owner or Admin to invite you from [Members](/platform/settings/members), or disconnect and sign in with the account you use for the dashboard.
The connection was revoked: someone chose **Disconnect** in **Connected apps**, you signed out everywhere, or (in Claude Code) the token expired or was revoked. Reconnect the connector, or create a new token and add the server again.
Your role in that organization is **Read Only**, or your Claude Code token has **Read API keys** access. Ask an Owner or Admin to change your role, or create a token with **Read and manage API keys**.
The Claude Code token wasn't created with the scope that tool needs — for example, asking about spend with a token that has only **Read API keys**. Tokens can't gain scopes: create a new token with the right access in **Settings → API tokens**, update the header in Claude Code, and revoke the old token.
A Claude Code token needs **Read endpoints & people** for machines, people and AI sessions, and **Read discovery** for repositories, cloud agents and their findings. Tokens can't gain scopes: create a new token with that access in **Settings → API tokens**, update the header in Claude Code, and revoke the old token.
Your token or connector has the access, but your Guardway organization doesn't serve that part to Claude yet, for example endpoints and people or discovery right after they were released. Nothing was changed. Use the dashboard for now, and ask Claude again later.
Each cloud connection refreshes one at a time and then has a cooldown of about 15 minutes. Claude says when you can refresh again. The latest results are already there: ask Claude to list your cloud agents.
Repositories are read-only from Claude. Open the repository in the dashboard and choose **Scan** (see [Repositories](/discovery/repositories)); Claude gives you the link.
Claude never sees prompt or response text. It can show the session's metadata, and Owners and Admins can read the text in the dashboard **People** view.
The change weakens protection or grants access — for example, turning a rule off, allowing every MCP server, a new application policy that allows what the baseline denies, switching an MCP tool on, inviting a member, rebaselining an anomaly, or adding models to a provider. Read the preview: it names what is affected, what gets weaker and the full before and after. Say yes in the conversation to apply it, or no to leave everything as it is. Claude never approves on your behalf. A preview expires after 5 minutes; if it has, ask again.
Someone changed the policy or guardrail rule (or, for an application's policy, the baseline), an alert rule, a provider or an MCP tool — in the dashboard or in another chat — after Claude read it, so Claude's edit was based on old settings. Nothing was changed. If the edit only adds protection and you hadn't approved anything, Claude reads the new settings and tries once more on its own. If you had approved a preview, or the edit would now weaken protection, ask Claude again: it shows a fresh preview based on the current settings for you to approve.
There can be only one policy for the organization baseline and one per application. Claude names the existing policy; ask it to change that one instead.
Requests the gateway couldn't price count as \$0 — often Azure deployment names. Claude says how many requests had no price; the real cost is higher by what those requests cost. Usage also lags real time by about an hour.
A reveal link works once and for 10 minutes. Ask Claude to rotate the key again to get a new link.
A link to enter credentials works once, for 10 minutes, and only for the member who asked Claude for it. Ask Claude for a new link: for example, "give me a new link for the OpenAI provider's key". **Link not found** can also mean you're signed in to another organization in the dashboard: switch to the organization you asked Claude about.
Claude doesn't pass keys, tokens or passwords from the chat to Guardway, and it didn't send the value. Ask again without the value, and Claude gives you a link to enter it in Guardway. Rotate the secret you pasted: it's still in your chat history.
Promoting a member to Admin, and inviting someone as Admin through Claude, need the organization's Owner. Ask the Owner to make the change, or invite the person as Read Only and have the Owner promote them.
An invitation can only be revoked while it's pending. The person is now a member: ask Claude to remove them as a member, which asks you to approve a preview first.
Claude added it, but nobody has saved its key through the link yet, so your gateways don't use it. Ask Claude for a new link to enter the key.
You belong to more than one organization. Tell Claude which one, by name.
## Related
* [API Keys](/platform/configuration/api-keys) — every key setting the connector can change.
* [MCP](/platform/configuration/mcp) — MCP servers and per-key tool rules.
* [Roles](/platform/settings/roles) — what Owner, Admin and Read Only can do.
* [Security](/platform/configuration/security) — guardrails and what each guardrail type does.
* [Audit Log](/platform/settings/audit-log) — the record of every change.
* [Users](/platform/settings/members) — members, roles and invitations.
* [Notifications](/platform/settings/notifications) — alert rules and webhooks.
* [Providers](/platform/configuration/providers) — every provider setting.
* [Guardway CLI](/discovery/guardway-cli/overview) — how machines report their AI tools and accounts.
* [Repositories](/discovery/repositories) and [Agents](/platform/agents) — the AI inventory in the dashboard.
* [Usage](/platform/dashboard/usage) and [Spend](/platform/dashboard/spend) — the same figures in the dashboard.
* [Pricing](/platform/settings/pricing) — the prices the gateway uses to compute cost.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.