Claude Pi Security connectorWhat Claude can do in your Pi Security account.
The Claude Pi Security connector exposes 21 tools: 14 read, 5 write, 2 undocumented. Most explain findings, threat models and pull request posture; five start work inside Pi. Here: what changes your tenant, what never touches your code, and who decides.
Verified Trustpilot reviews · AI, automation & growth agency
What the Claude Pi Security connector changes for AppSec work
With the connector, you ask Claude about a finding, an application's threat model or the secure way to build a feature, and Claude answers from the Pi tenant you signed in to. Pi's own repository lists which tools only look things up and which ones start work inside Pi.
A finding explained in plain words. Give a finding's FND display ID and pi_finding_get brings its details; pi_remediation_plan_fetch adds the existing remediation plan if there is one. Claude can compare it with another finding in the same answer.
Posture before a release. Pi pairs threat-model context, read through pi_threat_model_app_get, with the Code Gatekeeper pull request and issue posture, read through tools such as pi_gatekeeper_issues_list.
A design review started from the doc you already wrote. Give Claude a Confluence or Notion link and pi_design_review_url_create hands it to Pi for review; inline Markdown goes through pi_design_review_markdown_create.
What the directory sheet does not say. The five tools that change state in Pi start hosted work, such as a review, an ingestion or a plan; Pi says it never edits your local code. Attachments, PDFs, Word files and images are not passed to Pi through these tools. Two listed tools have no description anywhere. And nothing runs on a trigger: Claude calls the tools while it answers. For event-driven jobs, see automation platforms on the Integrations hub.
Five words before you connect
The Claude vocabulary you will meet around Pi Security.
- Connector
- The link you set up once between Claude and an account you already have, so Claude can work with it while it replies.
- Tool
- One named action a connector opens to Claude. Claude chooses the ones it needs; the directory sheet lists each of them by name.
- Authorization
- The service's own sign-in screen, where you grant Claude the access it will use. Granted once per person and revoked the same way.
- Approval
- The confirmation Claude waits for before it changes something in an account, shown in the chat when the moment comes.
- MCP
- The open standard connectors are built on: it lets an assistant like Claude reach an outside service through one shared interface.
Connect Pi Security to Claude in three steps
- 01
Locate it in Claude
In Claude's settings, open Customize, then Connectors, and find Pi Security in the list. On a Team or Enterprise workspace, an Owner or Primary Owner must enable it first so each member can sign in on their own.
- 02
Run the connection
Click Connect on its row, then sign in to Pi in the window it opens. If your account belongs to several tenants, Pi asks you to pick one there. If the link breaks later, Disconnect and connect again.
- 03
Check the authorization screen
Read the authorization screen before you approve it. It is Pi's screen, not Claude's, and it defines what the access covers. Once approved, the connector is ready in your next conversation.
The 21 tools, grouped by what they do
Pi Security gives Claude 21 tools: 14 that read your account, 5 that change something in it, and 2 no official source describes.
Fourteen consult your tenant, five start work in Pi, two are named and nothing more. Names stay as Claude shows them.
- 14 read
- 5 write
- 2 not documented
What Claude reads (14)
14 toolsLookups on findings, threat models, Gatekeeper records, playbooks and your own identity.
pi_finding_get
Opens one finding from its FND display ID, its UUID or its Pi finding URL, so Claude can explain it, summarize it or set it against another finding in the same reply.
pi_findings_list
Lets Claude list and locate the findings in your tenant, the starting point of the investigation workflow Pi describes, before it opens the ones you want explained.
pi_gatekeeper_issue_get
Pulls a single Code Gatekeeper issue by the UUID returned in an earlier list, so Claude can read it alongside the threat-model context of the same application.
pi_gatekeeper_issues_list
Returns Code Gatekeeper issues, each with the UUID Claude reuses to open one. Pi places it in its security-posture review, next to the threat-model tools.
pi_gatekeeper_pr_get
Reads one Code Gatekeeper pull request record, identified by a UUID taken from an earlier list, to show where that pull request stands in Pi's posture review.
pi_gatekeeper_prs_list
Lists Code Gatekeeper pull request records, giving Claude the UUIDs it needs to open any of them one by one during a posture review.
pi_knowledgebase_query
Queries the tenant's knowledge base for threat-model context. Pi reserves this generic lookup for context that is genuinely necessary, as one short query, and does not use it as a fallback when the playbook falls short.
pi_package_remediation_plan_fetch
Fetches the remediation plan that already exists for a package, given as a reference such as name@version, optionally with a vulnerability ID and its ecosystem.
pi_playbook_task_query
Brings back repo-specific secure-development guidance for a task. For a stable task Pi queries its playbook exactly once; if coverage is missing, Claude says so and carries on from your instructions instead of retrying.
pi_remediation_plan_fetch
Returns the existing remediation plan tied to a finding, which Claude can fold into its explanation. Pi lists it as an optional step of the finding investigation.
pi_threat_model_app_get
Opens the threat model of one application, named by its slug, so Claude can tell you what Pi records for it before you weigh pull request or issue posture.
pi_threat_model_app_section_get
Reads a single section of an application's threat model, both named by their slugs, when the whole model is more than the question needs.
pi_threat_model_apps_list
Lists the applications that have a threat model in your tenant, with the slugs Claude then uses to open one of them or one of its sections.
whoami
Returns the authenticated subject, the tenant and the granted scopes without exposing any credentials. Pi advises confirming the tenant this way before running other workflows.
What Claude changes (5)
5 toolsFive tools that Pi says change state in your tenant. Pi's own plugin asks for an explicit yes; for the chat connector, see the general rule below.
pi_design_review_markdown_create
Approval: see the ruleStarts a Pi design review from content pasted inline as Markdown or plain text. Pi then runs the review as hosted work, without editing your repository.
pi_design_review_url_create
Approval: see the ruleHands Pi the URL of a supported Confluence or Notion page so that it starts a design review from it. A PDF or a Word file goes through the Pi web app instead.
pi_package_remediation_plan_prepare
Approval: see the ruleAsks Pi to prepare a remediation plan for a package that has none yet. The plan is generated as hosted work in Pi; your code stays as it is.
pi_playbook_comment_create
Approval: see the rulePosts targeted feedback on the secure-development playbook. In that workflow it is the only step that writes, and Pi describes it as feedback only.
pi_report_markdown_upload
Approval: see the ruleSubmits a security report pasted inline as Markdown so that Pi ingests it. Files dropped into the chat are not converted; Pi points to its web app or the Sloane CLI for those.
Undocumented (2)
2 toolsThe directory lists these two names and nothing else. No official text says what they do, and this page will not guess from a name.
pi_design_review_get
This name appears in the directory's tool list, and that is all that has been published about it. Pi's repository does not cover it and no Claude page does either, so this page does not describe it.
pi_design_reviews_list
Same silence here: the directory lists the name, and no official source describes what it does. Saying so is more useful than a guess drawn from the wording of the name.
What Claude asks before acting
By default, Claude stops and asks before any action it takes on an account on your behalf. The prompt shows in the conversation when it matters.
On Team and Enterprise, owners decide whether members may let some actions through without a prompt each time. They can also cap what a connector does for the whole organization, keeping lookups open and closing writes, and nobody overrides that from their own account. Claude uses the rights of the signed-in person, nothing more. Pi describes a stricter contract in its plugin for Claude Code and Cowork: show the exact target, explain what Pi will do, wait for a yes, call once, never retry after an unclear failure.
Which plans include it
Out of 819 sheets in the official directory, none lists availability by plan. Connector by connector, that answer is published nowhere.
What is published is the general rule: remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile, and desktop extensions install on Claude Desktop. On Team and Enterprise, an Owner or Primary Owner turns a connector on for the organization before members can sign in. You also need a Pi Security account with access to at least one tenant. For the current status, open the Pi Security sheet in the directory.
Where this connector stops
A connector is not an automation. Claude calls these tools while it answers, and nothing fires when a new finding lands or a pull request is flagged.
The tool list is an observed floor, not a ceiling: an administrator can open actions that no public sheet shows. The partner badge is not a security audit, and Anthropic writes on every sheet that it does not choose a publisher's tools nor guarantee how they behave. Only Pi documents this connector, through its plugin repository; no Claude help article covers it. Other connectors are listed on the Claude connectors hub.
Need help connecting Pi Security to Claude?
A person reads every message.
