Connect a project

Before you begin: open your project in Grace, then choose Connect AI agent. For a project with no talents, Configure this project opens the same window.

Grace checks compatibility with MCP OAuth-compliant clients for the profiles tested. These setup instructions do not certify every version of Claude Code, Codex, or Copilot: qualifying those products requires an actual account and a verified connection. An observed Copilot request was replayed, but replaying it does not certify the commercial product.

1. Choose a setup methodCopy Anchor Link

The window offers two methods. Their purpose remains visible as a tag:

• Automatic — Recommended prepares the required files with a single command;
• Manual — Guided shows one file to install at a time.

You can switch between the methods without losing your progress in the manual steps.

2. Choose your environmentCopy Anchor Link

Under AI agent, select the tool you use, then choose Operating system. GitHub Copilot CLI and GitHub Copilot in VS Code are separate choices: the first configures the terminal, the second configures the editor. Grace waits for both choices before showing the appropriate steps.

3. Follow the displayed stepsCopy Anchor Link

Prepare the kit in a trusted project, with no other operation modifying or moving the affected files and directories. For an update, read the precautions and recovery guidance.

Automatic setupCopy Anchor Link

Copy Connect in one command and run it at the root of your repository. It prepares the AI agent configuration, instructions block, Grace procedures and, for Claude Code or Codex, the appropriate review profiles.

The command uses curl and sh on macOS or Linux, and PowerShell with Invoke-RestMethod on Windows. Preparing and checking the kit requires Python 3.10 or later; it is not installed automatically.

The terminal shows the project, AI agent, and prepared files. Once the files are ready, it shows the commands to authenticate and verify Grace. In simulation mode, it only shows planned operations and confirms no files were written.

A second run preserves a current kit. If older official instructions or personal changes are present, it stops before changing configuration: use Update Grace instructions, with a preview and explicit approval. If the MCP configuration already contains other servers, the command preserves them and adds Grace: it merges JSON formats with Node.js and appends a complete block to Codex and Mistral Vibe TOML formats. Without Node.js, an existing JSON file remains intact and an explicit error is shown. Invalid JSON or a symbolic-link file is rejected before any changes.

Automatic setup writes only to the current project, including .codex/config.toml for Codex. It never changes the user's global MCP configuration. Windsurf only supports a global MCP file, so Grace does not offer an automatic command for that agent and instead offers explicit manual steps.

Keep existing locationsCopy Anchor Link

The script first examines the selected agent’s compatible locations, separately for the instructions block and each of the four skills: grace-review, grace-discover-codebase, grace-update and grace-effort. An older official file is found, even when it needs an update. An unambiguous existing location is preserved. Identical copies are all accounted for; the script creates no compatibility file.

When an item is missing or copies diverge, the JSON diagnostic location_choice_required lists paths and options to pass again. Read it before choosing one of the supported destinations. The choice applies to this operation only: no permanent preference, migration, deletion or symlink is imposed.

ID is an identifier offered by the diagnostic, never a free-form path. For example, Antigravity accepts agents for .agents/skills and antigravity-legacy for .agent/skills. Add only the required options to the command copied from your project. Native profiles and MCP configuration remain those of the selected agent.

Manual setupCopy Anchor Link

Use Next and Previous to move through three preparation steps:

1. copy or download the configuration into the specified file;
2. copy or download the Wake the AI agent block into the instructions file;
3. copy or download each Grace procedure to its specified location.

Agents with a documented authentication workflow add a fourth step for authentication and verification. The Other agent · AGENTS.md choice retains three steps: Grace cannot invent commands for an unidentified tool. Only one step is visible at a time, but its contents are fully readable without an accordion. Paths use your system's format, notably %USERPROFILE% and backslashes on Windows.

The manual guide cannot read your disk. Check existing files before choosing the instructions file and the location of each skill. Menus come from the Grace compatibility catalogue and offer only compatible paths, alongside their loading conditions. .agents/skills appears first when compatible, without moving an existing installation. Each download shows its full path, for example .agent/skills/grace-review/SKILL.md. Choices are temporary; native profiles are listed separately.

Codex and AntigravityCopy Anchor Link

Codex uses AGENTS.md (or AGENTS.override.md, which takes precedence in the same directory), .agents/skills/<name>/SKILL.md and .codex/config.toml for MCP. Its TOML profiles in .codex/agents are separate from skills: absent profiles do not mean absent skills.

Antigravity is a distinct choice, separate from Gemini CLI. Instructions go in AGENTS.md or GEMINI.md; skills go in .agents/skills or the older .agent/skills, which remains compatible. Rules apply within their scope; skills are discovered at conversation start and activated according to the task. The workspace configuration is .agents/mcp_config.json:

{ "mcpServers": { "grace": { "serverUrl": "https://grace.example/mcp/example-project" } } }

Replace this fictional example with the configuration supplied by your project. Authentication remains a client step; Grace invents neither an Antigravity login command nor a native profile. Prepared files prove neither skill discovery nor successful MCP tool invocation.

4. Sign inCopy Anchor Link

Follow the authentication step when it is shown for your AI agent:

OAuth authorization opens in the browser when the AI agent initiates it. If Grace shows Choose a Grace account, select the account to use or Use another account to sign in with a different identity. Choosing an account does not grant permission: review the request next and select Authorize or Deny. If the request expires or the browser shows a validation error, close the page and restart authentication from your AI agent. Do not edit the authorization link; if the error persists, share its message with your administrator without sending the full link or a token. Check the named client and permissions before authorizing the connection. After signing out of Grace, reconnect your agent: refreshing a token will not restore a deleted session. If an old connection stops working after a Grace update, authenticate again. If access is still refused, select Connection failing? in the setup guide and follow the recovery instructions for your application. Signing in again may preserve the old OAuth registration; do not copy an old token into the configuration. If Copilot CLI interactive sign-in is unavailable, use the fallback shown by Grace: export GRACE_API_KEY in the terminal session, then apply the alternative configuration. Never copy the key's value into the repository.

You have succeeded when Grace is connected and its tools are available in your AI agent.

Enable a Grace Info pentest sessionCopy Anchor Link

For a visual explanation of the Docker image, the toolbox, and the AI’s role, start with Understanding pentesting.

Grace pentesting helps improve code quality by identifying weaknesses to fix. Security is a chain of value: design, development, checks, monitoring, and incident response complement each other. Pentesting contributes to that chain but does not replace your cybersecurity tools or specialist teams. A result with no findings does not guarantee there are no vulnerabilities.

In your project, open Settings → Security, then Connect agent. This dedicated connection is separate from the usual Grace MCP. On the machine running your AI agent, Docker must be installed and running, with Buildx available. Docker Desktop includes it on macOS and Windows; with Docker Engine on Linux, install the official Buildx plugin. The Docker engine runs Linux, even on macOS and Windows: you do not need to run Linux on your computer. On Windows, choose Linux containers in Docker Desktop.

The Docker prerequisites and checks section provides commands to run in your agent's terminal and their expected results; the browser cannot check your installation and therefore does not show an "installed" status. You will need an internet connection to download tools and must allow your agent to run Docker locally.

Then choose your AI agent and operating system. The window shows the dedicated command or two manual steps; it starts no containers or tests and does not change the project's talents. Buildx will build the tools image after your approval, then the agent will run the isolated container: you do not need to write a Dockerfile.

Before preparation, retrieve the project's required talents in your usual Grace session, without sending target data or test results. Keep the served instructions locally, then open a separate preparation session in which only the grace-pentest server is active. The general Grace server exposes tools that are not designed to receive campaign data.

Before loading application data or starting tests, freeze the local preparation files, disable every Grace connection, including grace-pentest, and remove its credentials from the parent agent and any child contexts. Changing phase does not authorize another Grace call. The operator and AI tool must enforce this separation; an instruction alone does not isolate credentials or tools.

On macOS or Linux:

curl -fsSL 'https://grace.hoppr.tech/setup.sh?profile=pentest' | sh -s -- --project '<projet>' --harness codex

On Windows:

& ([scriptblock]::Create((Invoke-RestMethod 'https://grace.hoppr.tech/setup.ps1?profile=pentest'))) -Project '<projet>' -Harness 'codex'

Replace codex with your chosen AI agent and <projet> with the reference shown in Grace. The script installs no scanner, broker, or agent engine. It only configures the restricted MCP and confidentiality instructions. If it still finds the general Grace server in the same file, a declaration different from the expected one, or a linked path, it stops without changing any files. The pentest profile requires its exact isolated configuration: keep your usual configuration separate without overwriting it.

Reload MCP, then sign in through OAuth. You have succeeded when the agent shows the two tools grace_pentest_local_toolbox and grace_pentest_guidance for this server. The first prepares the tools' public files for the Docker architecture; the second accepts only three choices — phase, AI agent, and language — and returns versioned instructions. Secrets, evidence, findings, and campaign reports stay on your system, not with Grace.

Reconnect to your usual Grace server only after the campaign has stopped and cleanup has been verified, in a separate session without campaign data.

Choose the target in GraceCopy Anchor Link

Under Settings → Security, the dedicated local instance is selected by default. Only an organization owner or administrator can change the policy; members can view it. Adding a target starts no tests.

Open Add a remote target, then enter the Website address over HTTPS, without a path or credentials. You can specify a port. By default, the scope covers the entire site (/), without its subdomains. In the Included paths and Excluded paths fields, enter one prefix per line; exclusions take precedence. A summary shows the scope before you add it.

Click Add target. The Verify domain section shows the DNS name and value to publish with your hosting provider. Once the record is published, click Verify DNS proof. The challenge expires after 15 minutes and a verified proof lasts 24 hours. When it expires, Renew DNS challenge gives you a new value to publish. A concurrent change requires reloading the policy; your input is preserved.

Deletion requires confirmation and also removes the DNS proof: you must verify the domain again before reusing it.

Remote execution remains unavailable, even after verification. DNS proof demonstrates control of the domain, not legal authorization to attack it. An expired remote target stays selected but blocked: Grace does not automatically switch to another target.

Choose tests and AI effortCopy Anchor Link

The Tests section shows profiles and AI effort. Choose a profile to prepare the selection, then open Test list to adjust it:

Under Test list, select or deselect each family to adjust the selection. The profile becomes Custom. Risks, blockers, and incompatibilities with the target stay visible on each row; Details and tools opens its description and associated tools. Selecting a test does not necessarily make it available: Full does not remove any blockers. The Quick profile allows the four offline analyses after you approve the files or captured responses to inspect. Code analysis covers three targeted rules, not all vulnerabilities. Local HTTP authorization, authentication, injection canary, and business logic checks are also available with authorization. Image configuration analyzes approved Dockerfiles and Kubernetes configurations, not image archives or Terraform. TLS configuration tests only a dedicated local instance: its certificate for localhost and whether it accepts obsolete TLS 1.0/1.1 protocols. It does not test the public certificate or remote infrastructure. Browser security checks CSP and X-Frame-Options protections of captured responses offline: it does not visit your application or run its HTML. Known vulnerabilities searches approved responses only for an X-Powered-By header and jQuery version banners associated with CVE-2020-11022/11023. A matching banner is not proof of exploitability; its absence is not proof that the dependency has been fixed. This is not an exhaustive search for known vulnerabilities. The Local laboratory only tag marks tests reserved for a disposable local instance. The four advanced laboratory test families are not yet available in Grace: their integration for execution has not been validated. This is not a configuration problem with your project. You can include them in the selection, but they will not run.

Choose Economy, Balanced, or In-depth effort separately, then click Save tests. The requested budgets are 20,000, 60,000, and 150,000 tokens respectively: they are guidance for your agent. Grace does not measure or cap consumed tokens. A strict limit must be enforced by your AI tool; this setting alone does not enable it. More effort does not authorize additional actions or change the selected checkboxes. The save button appears after a change; the summary flags an unsaved draft above the settings.

Organization members can change these choices without obtaining permission to edit targets. You have succeeded when the saved selection is retained after a refresh. Saving does not start containers. If a concurrent change occurs, reload the policy, then explicitly choose to replace your draft before retrying.

Your agent reads the selection when preparing the session. To change tests during a session, stop it and prepare a new one: changing the screen does not stop an already running session. Blocked or unperformed tests must be reported as such.

Build the tools with your AI agentCopy Anchor Link

Install Docker Desktop on macOS or Windows (in Linux containers mode), or Docker Engine and its official Buildx plugin on Linux. Buildx is included in Docker Desktop. You do not need a Grace client, Node.js, host browser, image archive, or DevBox. You do not write a Dockerfile. Appium and Xcode are not prerequisites for Web/API pentesting.

1. In your pentest preparation session, ask your AI agent to prepare the tools through Grace.
2. Approve the download of public dependencies and local build. The agent fetches files from Grace, checks their hashes, and uses Docker Buildx.
3. Check the built image identity and selected tool versions shown by the agent. Building the image starts no campaign and does not prove that its tools work. HTTP, browser, and PDF diagnostics, then security tool presence, version, and operation checks, have separate results.

The build runs on your machine; no CI runner or CI execution is needed. The image contains the tools and local campaign components. Your AI remains in Codex, Claude Code, or the tool you chose. The agent extracts the launcher for your operating system and architecture from the image, then verifies its hash. This launcher uses Docker; Node.js and the coordinator remain in containers. Keep the launcher in the designated private directory.

Each preparation checks the latest stable versions of the tools and the compatible Chromium image, then pins them for the session and its retest. If a version is missing or incompatible, preparation stops rather than silently reverting to an older version. System dependencies remain those of the official image.

Preparing a skill provides a versioned local method. It does not prove that subagents have started or that tests are available. If preparation reports blocked execution, keep that status until the required capabilities have been verified.

Conduct tests with your AICopy Anchor Link

After preparation and campaign approval, the AI chooses useful checks from those permitted for its mission and uses their observations to decide what to do next:

1. The AI receives the mission, allowed tools, limits, and observations already obtained.
2. It requests a specific operation. The local controller checks scope and budgets, then runs the tool in the designated container. The AI receives no unrestricted toolbox terminal.
3. It examines the observation, requests the next check, or concludes. A refusal, incomplete output, or uncertain operation interrupts that workflow.
4. Read findings, evidence, and limitations in the report MCP App if your tool supports it, or retrieve the private HTML export. PDF requires verified local rendering.
5. After reading, select findings to fix and confirm a correction authorization specifying the data sent to the AI. Reading changes no files. Retesting also requires an appropriate scope and approval.

You have succeeded when the report distinguishes operations actually performed, validated findings, and what remains unverified. A listed tool does not prove qualification on your machine. MCP support alone guarantees neither App display, human forms, nor separate AI contexts: verify these capabilities in your agent version. A launcher for your operating system alone does not qualify tool execution, report display, or human confirmations.

Authorize offline analysesCopy Anchor Link

Ask your agent to run the available analyses in your selection. It first shows you the files or previously captured HTTP responses to inspect, the duration, and the number of analyses allowed. Scanners run in a separate container, without network or direct access to the repository. HTTP observation sends no new requests.

For Browser security, approve one to five distinct HTML responses that have already been captured. The check determines whether their headers allow a test script embedded in the page to run or allow the page to be displayed inside a frame from another site. It uses synthetic pages, without your scripts or cookies. An alert indicates missing or permissive protection, not a successful attack. This check does not replace testing application workflows.

Keep the local report and its evidence. It distinguishes candidate alerts, analyses without alerts, incomplete analyses, and tests not performed. No alerts does not mean no vulnerabilities. After an approved fix, request a retest on the same files or captured responses, with the same tool versions. A scope change or analysis failure must not be presented as a successful fix.

Test an already running local applicationCopy Anchor Link

Existing application mode keeps your Web application or API running on your machine as it is. Your operator prepares the exact local addresses and ports, included and excluded paths, test accounts, declared version, and external dependencies in use. The pentest does not start, stop, reset, or containerize this application. Docker remains required for the campaign engine and reports. The application does not need to be exposed to the Internet: tests use its local addresses.

Before approval, verify that the application uses only the intended synthetic data. Missions share the same state: any creation, modification, or deletion you approve may persist after testing ends. Declared external dependencies remain under your control; this mode does not block the application’s outbound connections.

Available checks cover authorization, authentication, injection canaries, and business logic over HTTP(S). Requests target only the approved loopback addresses, without following redirects. Network discovery, active scanners, and desktop or mobile interface automation are not included in this mode. Installing Appium does not enable this interface automation in this workflow. The version recorded in the report is a declaration, without proof of the source revision actually running.

After cancellation or completion, only pentest requests and resources are released. Your application remains running and its data is not restored. The report retains this limitation; revision-linked retesting is refused in this mode. Start a new independent campaign with fresh human approval to reassess the application.

Authorize local HTTP testsCopy Anchor Link

This section describes the isolated laboratory, separate from existing application mode above.

The agent must prepare a dedicated instance of your application, with no real data, separate from the tools container and without external network access. Confirm the scope, test accounts, permitted actions, duration, and maximum number of requests before authorizing it.

The experimental profile accepts bounded HTTP requests without following redirects. An incomplete response stops the session without automatically retrying. If your application cannot run in this isolated profile, the agent stops: it does not replace it with a mock application or switch to a remote URL. Browser scans against a target are not available.

After the requests, ask the agent to stop the test session, preserve the evidence, and generate the HTTP observation summary before deleting the containers. It distinguishes families with observed responses, incomplete results, and untested families. Receiving a response proves neither a vulnerability nor that all tests in a family were run.

Separating technical missions alone does not authorize autonomous AI agents: their access to tools must also be verified. Do not give them a general-purpose terminal to bypass a blocker. Before sharing application responses with a model, confirm the allowed data and the provider used; a local toolbox does not mean the model runs locally.

Prepare a campaign across several servicesCopy Anchor Link

The experimental local workflow accepts previously built service images, regardless of their language. Your operator prepares immutable images, ports, and startup order in the local Linux Docker engine. Preparing an image starts no campaign. The launcher requires the engine and each image to match the host architecture, amd64 or arm64; it rejects remote engines and incompatible images and does not select emulation. Laboratory tool recipes cover both architectures, but the actual images and tool versions still need verification on yours.

The current profile accepts up to sixteen disposable services, with per-service resources and temporary storage shown before approval. It does not automatically build your application, import Compose, or grant internet access. A test database uses this temporary space; its state is not retained between missions. A background process can run without a network port: its running status does not guarantee that its work or dependencies are ready. The Docker workflow requires no host Node.js. The operator can prepare an image with an explicit startup command or retain its existing one. The resulting local receipt is not certification.

Before accepting, check services, fictional accounts and organizations, observation recipient, and budgets. Reads are allowed by default. Operations that create, modify, or delete test data must appear explicitly in the mission plan; read authorization does not cover them. The AI cannot add arbitrary credentials, headers, or programs. Real data remains excluded.

For applications using session cookies, the operator can prepare real sign-ins with fictional accounts at the start of each mission. This mode appears in the approval plan. Sessions remain private and confined to their service; the AI chooses only an authorized account. A missing session blocks the mission. Sign-in is not automatically renewed: logout can therefore test that the same access is subsequently denied.

The operator can also attach approved copies of files or previously captured responses for offline analysis. Approve these copies and their analysis budgets before the campaign. The AI chooses only among approved copies and families, never arbitrary host files. Model-facing outputs are reduced, while original evidence stays private; reduction does not guarantee anonymization.

Specialized checks can be prepared for local encryption, fictional password hashes, a test parameter, or a synthetic JSON connection. Images, paths, candidates, and limits are chosen before approval. These prepared scenarios do not unlock every advanced laboratory family.

The report groups findings about the same scenario while retaining references, proposed severities, and validations. Conflicting validations remain Unconfirmed. This workflow still requires a compatible human confirmation and separate mission contexts. Tool presence alone does not qualify your model or harness.

Verify a fix in a new campaignCopy Anchor Link

After the initial report, agree with your operator on the responses expected after the fix and the legitimate access that must remain possible. Freeze these expectations before recording the corrected version. Code changes are a separate task requiring your approval; the launcher applies no automatic fix.

The operator then prepares a new campaign on the corrected version with the same services, accounts, permissions, budgets, and tool versions. Fresh human approval is required before requests. Campaign retesting compares HTTP responses, including their contents, with the frozen expectations. It does not infer success from the AI's text or a disappearing finding. Scanner retests remain separate analyses.

The new HTML/PDF report shows expectations and checks as satisfied, failed, or incomplete, and references the initial report without replacing it. Missing, repeated, or incomplete probes prevent a favorable conclusion. A changed scope or tool requires a new assessment, not a comparison presented as a successful fix.

Try the invoice laboratoryCopy Anchor Link

To verify the workflow with fictional invoices, the portable campaign launcher can chain discovery, verification in a new AI context, and an HTML/PDF report, after limited initial approval. By default, it stops at the report: no fixes or post-fix retesting. It uses the shared MCP workflow and does not require MCP Apps. Ask your operator to prepare the launcher, its verified local tools, and the local MCP server in your usual AI tool. The AI uses your subscription or the provider already configured in that tool; you do not need to configure an AI provider key in Grace. Interactions use ordinary MCP tools, without limiting this workflow to Claude Code, Codex, or any other brand. Your tool must, however, be able to run each request in a separate tool-free context, display the required human form, and pass on refusals without bypassing them. If it cannot, cancel the campaign: support for MCP alone does not guarantee this capability. This laboratory does not target your client application. Two separate contexts do not certify that the agents are independent.

Before accepting, check the model, data sent, and limits: at most two missions and sixteen HTTP observations. Declare the recipient that matches your local configuration and do not change it during the campaign. Reports and evidence stay local; the AI provider receives fictional observations and a description of the finding. This mode does not send source code to the model or call Grace. A later fix requires a new preparation and approval that explicitly covers it, with the project's security talents already prepared locally.

A provider refusal, error, or interruption stops the campaign without automatic restart, rephrasing to bypass the refusal, or changing the model or provider. Local authorization does not override the AI provider's policy or guarantee it will accept the mission. The report does not replace your review and acceptance of the document.

The form presents the scope, exact prompt, AI recipient, budget, and expiration. Confirm or refuse directly in your tool: the agent cannot answer for you. A sentence in the conversation does not replace this confirmation. Without a compatible form, the decision is refused and no agent may start. Reading and private export remain available.

Approval covers only the presented campaign. Check its name, recipient, disclosed data, budgets, and expiration before confirming. No laboratory starts while approval is pending. Refusal, expiration, or uncertain execution requires a new preparation; reopening does not restart work. Report review and correction confirmations remain separate.

Approving the target does not replace authorization from the AI provider. If OpenAI shows cyber_policy, stop the mission and see the Codex cyber safety and Trusted Access rules. For Claude, see the cyber safeguards and Cyber Verification Program. Check the conditions applicable to the account, organization, model, and tool actually used. Specialized cyber access is not a general Grace setup requirement; some operations may be refused or subject to provider-specific conditions. Do not change models, accounts, or wording, or execute a tool directly, to bypass a refusal. Use the official false-positive reporting procedure or specialized access procedure when it actually applies. Personal approval does not automatically cover a service offered to third-party clients.

If a campaign appears stuck, ask your AI tool to read its recorded state or open its local monitor. Reading starts or resumes no test. Check the last activity, refusals, and cleanup evidence before another action. A stop request does not confirm cleanup; a completed campaign does not certify project security. Monitoring data stays local and is not sent to Grace.

Keep the evidence export in a private folder on your computer; the summary does not copy response URLs or contents. It does not turn observations into confirmed vulnerabilities. For the synthetic invoice laboratory, then request a new report based on completed missions. It distinguishes recorded responses, scenarios reproduced locally in two missions, and untested areas. Missing provenance remains flagged; this document certifies neither project security nor independent AI validation. Access to another account's invoice may already appear as a candidate finding, even if the reverse direction was not tested. The report describes only access supported by evidence; an incomplete observation does not make other observed findings disappear. The old report and its approvals are not replaced. After an approved fix, you can request a local HTTP retest: keep the tools, accounts, and test data from the campaign. Before any new request, specify the responses expected after the fix and the legitimate access that must remain possible. The agent locks in these expectations, replays only the authorized probes on the corrected version, then compares before-and-after evidence.

A stopped application, incomplete response, leak despite a denial, or broken legitimate access must not be presented as a successful fix. If response contents vary, the comparison may remain inconclusive. Observations matching expectations do not certify application security; making a fix and validating it remain separate decisions. Tests on a mock application prove the mechanism, not your project's security or independent AI validation. The profile was exercised on macOS Apple Silicon; Windows and Linux still need qualification.

Authorize a local TLS checkCopy Anchor Link

If TLS configuration is selected, request a separate check on the dedicated local instance. Confirm its port and the stated budget: one scan, at most 256 connection attempts on that port, and 60 seconds. The agent checks the certificate for localhost and acceptance of TLS 1.0/1.1. A self-signed local certificate is normally reported as untrusted; this does not demonstrate a problem with the public certificate. After a fix, retest with the same port and tools. A closed port or interrupted analysis produces an inconclusive result, not a fixed vulnerability.

End the sessionCopy Anchor Link

Fixes are a separate coding task, subject to your approval. At the end of the session, ask the agent to preserve the evidence, stop the containers it created, and verify their removal. Cached images and evidence you saved separately are not deleted.

Review a report with or without an MCP AppCopy Anchor Link

Monitor a recorded campaignCopy Anchor Link

If your operator configured the local campaign monitor, ask to open it. In a tool supporting MCP Apps, Refresh status rereads recorded missions, observations, and limitations. The date and revision show the last known write; they do not prove a controller is still running. Opening or refreshing this view starts or resumes no test.

When a report is available, choose Read report, then Download PDF. A message saying that download was requested from the host records a request: check that you actually receive the file. Without integrated download, Export private PDF saves it with the operator. Export private HTML remains available when PDF cannot be produced. An export failure does not hide an already opened report.

Without an App, request a private HTML/PDF export of the same report and retrieve the file from the operator. Recorded monitoring and results remain readable after reopening without replaying missions. Incomplete states and reports with no findings retain their limitations. This view is read-only: it neither accepts the report nor authorizes corrections. The reader with decisions described below is a separate workflow.

Use the report reader and its decisionsCopy Anchor Link

An MCP App is an interactive view displayed by a compatible client. The local report server must have been installed and configured by the operator with a redacted report. It does not start tests or send the report to Grace; the client displaying the App receives its contents. Check that client's privacy rules too.

The report starts with Key takeaways and Priority actions. Each finding explains the problem, its potential impact, the recommended action, expected behavior, and observation. Scope and limitations distinguishes what was observed, blocked, interrupted, or not tested. "Observed" does not mean "secure"; severity remains a suggestion, without a calculated CVSS score. In the App, Candidate means "to be confirmed" and Reproduced locally means "reproduced locally." Accepting the report changes neither these statuses nor the status of fixes.

Explained checks presents each attempt with a descriptive name, its result, and preserved observations. For invoice checks, read Expected, Observed, then the consequence: for example, an invoice shown to the wrong person. The protection already present in the laboratory serves as a comparison: it is not a fix to the vulnerable version. A Pre-fix confirmation reproduces the problem; results of any post-fix test appear in a separate report. Cross-references name the check rather than showing just a number; they are clickable in the HTML export and remain text in the App. Technical data is collapsed in both readers. It helps find original files, not understand the outcome. HTML, PDF, and App present the same facts. Generating a new report does not replace old files or their approvals: review the new document before accepting it. When rendering a report, choose --locale fr or --locale en; without the option, it is in English. Only the HTML/PDF presentation text changes language: JSON and free-form finding data are not translated. The PDF uses a fixed layout: summary, named and colored severity levels, finding sheets, recommended actions, limitations, then explained checks. Long technical references remain in the private files accompanying the report, not its reading pages. The footer on each page shows the current section, even when it spans several pages. To search or copy text, prefer HTML: some ligatures may not be accurately reproduced in extracted PDF text.

1. Open the local report and read its limitations: a scenario reproduced locally is not certification; other observations may remain candidates.
2. Download PDF asks the client to save the PDF generated from this same report. Without integrated download, Export private PDF saves it in the operator's private folder. Retrieve it using your client's file features or ask the operator.
3. Accept reviewed report opens a client confirmation. It records an acceptance relayed by that client, not independent evidence of human presence, a vulnerability, or project security.
4. Select the observations, then Request fixes for selected findings. A second confirmation presents the selection to be sent to the AI agent and its provider. Once approved, the agent receives a request for targeted checking and fixes using the project's security talents already prepared locally, without reconnecting to Grace or authorizing deployment.

If the App is not displayed, request a private HTML or PDF export. Retrieve the file from the operator through your client's private file access, then read it locally. Nothing is automatically published. If PDF is unavailable, HTML remains readable. Do not load the report into the model's context without separate disclosure approval.

1. After reading, ask to accept the report. A compatible client opens a human form bound to that document; confirm or refuse directly in the form.
2. Provide the identifiers of findings to fix. A new confirmation must show the project, AI recipient, and selected details that will be disclosed. Accepting the document alone authorizes neither sharing nor corrections.

A request expires after ten minutes; prepare a new one if needed. Without a compatible human form, decisions are refused and only reading and private export remain available. A sentence relayed through the conversation never replaces the form. The client remains trusted; this is not independent human authentication. Sharing the whole report with the model requires separate approval and is unnecessary for selecting findings in your private copy.

A refusal preserves the report. If delivery is uncertain, check the conversation before making another request; there is no automatic resubmission. A sent request does not prove that a fix or retest happened. Restarting the server requires new confirmations, but exported files remain available. No decision is recorded in Grace.

If it does not workCopy Anchor Link

See also Troubleshooting and MCP tools.