Act MCP server integration

Act’s MCP (Model Context Protocol) server connects the assistant or agent you already use to your cloud access map, allowing you to query it in natural language. The assistant can investigate principals, access paths, boundaries, and policies across your environment, and answer questions about hardening campaigns, operations, and action items used to close security gaps.

For access, ask who can reach a resource, what a principal can access versus what it has actually used, or which services are reachable from outside the organization. For hardening, investigate campaigns that ring-fence production cloud AI agents, restrict unintended inbound external access, or eliminate privilege-escalation paths. You can also ask what an operation changes, check the audit status of your action items, or see what a simulation would break before you enforce it. Responses are grounded in your environment's actual data in Act.

The MCP server works within the assistant you already use; there is no separate interface to access, no need to transfer findings between tools, and no additional query language to learn.

Connecting to Act’s MCP server

You can connect in two ways: interactively as an individual user, or programmatically as an automated client.

Connecting as an individual user — a person working in an AI assistant, authenticating with an Act portal email and a one-time code, or single sign-on.
Connecting as an automated client — a headless client such as a backend, agent, or CI job, authenticating with a per-tenant client ID and secret and no human login.

Connecting as an individual user

Connect from your own AI assistant with interactive sign-in.

Prerequisites

An Act portal account — the same login as the Act web app.
An MCP-compatible client.

Connect and authenticate

The steps below use Claude Code as an example.

From your local terminal, run the following command.
```
claude mcp add --transport http act https://mcp.act.security/mcp
```
act is a local label — you can choose any name.
Start your MCP-compatible client. For Claude Code, run claude.
Run /mcp, select the act server, and choose to authenticate.
Sign in with your Act portal email and the one-time code that Act sends you.
- Alternatively, you can use single sign-on if your organization has it. There are no API keys to create.
Start asking questions about your environment.

Connecting as an automated client

Automated clients such as backends, agents, and CI jobs connect to the Act MCP server without a human login. You can currently connect with a service account.

Connecting with a service account

A service account lets headless clients (backends, agents, CI) connect without a human login. Access is read-only, similar to interactive sign-in. The only difference is the way identity is verified.

Prerequisites

You need service account credentials for your tenant.

How to obtain your service account credentials: Until self-serve provisioning is available on the platform, Act’s admin will create an MCP integration for your tenant and securely share the client ID and secret.

Configure the client

Configure your LLM client to use the Act MCP endpoint and with the following headers:

Act-Client-Id Act-Client-Secret

The following is a sample Claude MCP configuration:

{
  "mcpServers": {
    "act": {
      "type": "http",
      "url": "https://mcp.act.security/mcp",
      "headers": {
        "Act-Client-Id": "<client-id>",
        "Act-Client-Secret": "<client-secret>"
      }
    }
  }
}

Using the Act MCP server

Ask your first questions

The assistant picks the right read-only tool for each question; you do not choose tools yourself. For example:

Can app aws-application-core-app write to the S3 bucket storage-prod?
Can app azure-billing-app reach the Azure SQL server billing-prod?
Which of our services are reachable from outside the organization?
For this principal, show what it can access vs. what it has actually used.
Which operations close the exposure on the S3 bucket storage-prod?
What campaigns are open for the production environment?
What's the audit status of my action items?
What would a simulation show before I enforce this change — would anything break?

Key concepts: configured vs. observed access

Configured access is what your setup permits. Observed access is what your logs show was actually used. When logs (CloudTrail data events, flow logs) are off, observed can appear empty even when access exists.

Scope and limitations

Model — Claude Sonnet is a suitable default for these queries.

Read-only — Both connection methods are read-only; role-based access control is not yet available.

Identity — Interactive sign-in is per-user and scoped to the user; a service account is per-tenant and for headless clients.

Issues signing in — Use the email one-time code, confirm your Act account is active, and prefer the Claude Code command-line tool if an editor extension fails.

Questions or feedback?

Contact your Act point of contact or your shared Act channel — the server is evolving quickly, and your input shapes it.

Documentation Index