You can read Security's findings and act on them from the chat assistant, or from your own assistant through CoRoid as an MCP server: Claude Code, Codex, Cursor or another MCP client. The tools follow the same rules as the portal, so they give the same answers and refuse the same things.
Reading
Security has scopes of its own, so a connection made for other work does not
see findings. These tools need the Reviewer role and mcp.security.read. None
of them needs approval. They follow CoRoid Security's own rules: you see the
projects you can see in the portal. A connection limited to some projects must
name one of them, or a finding of one.
| Tool | What it answers |
|---|---|
get_security_overview | Per project: open findings by severity, past their fix date, claims nobody confirmed, test code, and how many wait for you |
list_security_findings | Findings by project, kind, severity and state, exploited first, then by severity; needsYou keeps only those that wait for a person |
list_security_needs | What waits for a person, most urgent first, and how many in all: the Factory's Needs you |
get_security_finding | One finding: where it is, whether it was confirmed, when it is due, and its fix work. Never a secret's value |
get_security_settings | Each protection of a project as checks apply it: off, observing, enforcing or unable to run, and why, with what the project's setup chose |
list_security_runs | Security's runs, newest first, as the run log lists them: running, waiting, completed, failed or replaced, and why a run failed |
get_attack_surface | Each project's entry points and how many wait for an exposure; for one project, every entry point with what the code shows and what people decided, deployment suggestions, and what the pull request guard found |
get_threat_model | Each project's threat model version and what waits for review; for one project, the model, the proposal that waits, and the latest versions |
list_security_packages | Each project's latest dependency inventories with how many packages they install and how many are vulnerable; for one project, its packages a page at a time, vulnerable first |
Every finding links to its page in CoRoid.
Acting on findings
These tools act on findings. They need mcp.security.write and an owner or
administrator, as in the portal.
| Tool | What it does | Approval |
|---|---|---|
start_security_fix | Fix, as in the portal: fix work for a vulnerable dependency, a task with a regression test for a code finding, the rotation checklist for a leaked credential. A second Fix answers the task already filed | No |
run_security_scan | Scan one project now: everything that is on, dependencies, the secret history, the attack surface, the audit (where it is on) or kept proofs | No |
confirm_real_secret | Confirm a leaked credential is real. It stays open until someone attests it was rotated | No |
revoke_security_exception | End an exception: the finding is open again | No |
dismiss_security_finding | Mark a finding Not a problem, with a reason | Always |
add_security_exception | Accept the risk of a finding until a date, with a reason | Always |
attest_secret_rotated | Attest that a leaked credential was rotated or revoked, which closes it. CoRoid never tests a credential it finds | Always |
Acting on the attack surface and the threat model
These need mcp.security.write and an owner or administrator too. Where one
control in the portal both strengthens and weakens, there are two tools: the
one that strengthens refuses a change that would weaken, so that change always
goes through the one that waits for a person.
| Tool | What it does | Approval |
|---|---|---|
raise_entry_point_exposure | Make entry points more exposed, pin them for the audit, or bring them back in scope | No |
lower_entry_point_exposure | Make entry points less exposed, take a pin away, or put them out of scope with a reason | Always |
refresh_threat_model | Read the project's code again; what it finds waits as a proposal | No |
add_threat_model_entries | Add entries to the threat model | No |
accept_threat_model_proposal | Accept what a fresh read of the code proposed | No |
update_threat_model_entries | Change an entry's title or detail | Always |
remove_threat_model_entries | Remove entries from the threat model | Always |
dismiss_threat_model_proposal | Dismiss what a fresh read of the code proposed | Always |
keep_security_proof | Keep a proof that reproduced a finding as its regression test | No |
Changing protections
A protection's settings, for one project or the organization default, in the
same two tools: tighten_security_protection makes a protection stronger and
refuses any change that weakens it, and relax_security_protection makes it
weaker, or has a project follow the organization default again, and always
waits for a person. A change weakens when detection or enforcement is turned
down, a severity threshold goes up, fewer fix pull requests may open, the
audit is turned off or runs less often, the secret scan reads less, the
sandbox network opens up or allows more hosts, or a "not set" entry point no
longer counts as internet-facing. "Your own scan command" is set in Quality
Control.
Contacts and disclosure
A project's security contacts hold the disclosure authority beside owners and administrators: they see the fixes CoRoid holds privately for undisclosed findings, publish or discard them, draft GitHub security advisories and record reports to a dependency's maintainers. Through MCP and Chat these calls are for owners and administrators, and every one waits for a person: a contact can disclose findings, and disclosing a finding cannot be taken back.
| Tool | What it does | Approval |
|---|---|---|
list_security_contacts | A project's security contacts, and who could be one | No |
get_security_disclosure | A finding's private fixes (size and state, never their content), its GitHub advisory and the reports sent to maintainers, for the disclosure authority | No |
add_security_contact | Make a project member a security contact | Always |
remove_security_contact | Remove a security contact | Always |
publish_private_fix | Publish a held fix: the finding becomes disclosed and a task opens its pull request | Always |
discard_private_fix | Discard a held fix | Always |
draft_github_security_advisory | Draft a GitHub security advisory in the repository, visible to its maintainers | Always |
record_maintainer_report | Record where you reported the finding to a dependency's maintainers. CoRoid sends nothing | Always |
Why some actions wait for a person
Not a problem, an accepted risk and a rotated credential each take a finding off the open list without a fix; a less exposed entry point and a smaller threat model each take something out of what the audit looks at. An assistant should not be able to do that on its own, so these tools always wait for a person, whatever the connection's settings:
- From an MCP client, the call waits for an owner or administrator in Settings → Connections → CoRoid MCP server → Approvals, and they get a notification. The request expires after 10 minutes.
- In Chat, the assistant asks you to confirm in the chat before it acts.
The approval says in plain words what happens, built from CoRoid's own record
of the finding: "Mark Broken access control in src/routes/admin.ts:76 (Shop)
Not a problem", followed by the reason in quotes. The words around the reason
come from CoRoid, never from the assistant, and a credential's value never
appears: CoRoid does not keep it.