> For the complete documentation index, see [llms.txt](https://support.attackforge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.attackforge.com/app/getting-started.md).

# Getting Started

## Getting Started

AttackForge is where your offensive security work happens, from the first request for testing to the final retest. This page walks you through how the platform fits together, who does what, and how an assessment moves through its lifecycle. Each section links to a detailed guide.

## The platform at a glance

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2F8wC6St1pTcMmJe5GNWBA%2F01-platform-overview.png?alt=media&amp;token=ffb288b7-ef5c-40d5-929b-12788d261aab" alt=""><figcaption></figcaption></figure>

AttackForge brings everything a security assessment needs into one platform: requests, projects, scope, testing, findings, reports and remediation. Spreadsheets, shared drives and email threads stop being the system of record.

* **Security consultancies and MSSPs** run engagements for many clients, each with their own access and branded reports.
* **Internal security teams** manage testing demand across the business and track remediation through to closure.
* **Everyone works from the same data,** so testers, managers and the people fixing the issues always see the current picture.

## The assessment lifecycle

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2FWuHa4GUWkRj7xHhpSa8Q%2F02-assessment-lifecycle.png?alt=media&amp;token=f2111bde-ed99-4666-8bce-5d629b846963" alt=""><figcaption></figcaption></figure>

Every assessment follows the same lifecycle: request, set up, test, report, remediate and retest. Each stage feeds the next, so nothing has to be re-keyed and you keep a full audit trail.

1. **Request:** someone asks for testing and describes the scope.
2. **Set up:** the request becomes a project with its scope, team, timing and test suites.
3. **Test:** testers work through test cases and record findings with evidence.
4. **Report:** findings become a report using your templates.
5. **Remediate:** asset owners fix the issues and record what they did.
6. **Retest:** testers confirm the fixes, and the findings are closed.

## Roles and responsibilities

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2FN7X837DnCe8TuGitTiyS%2F03-roles-and-responsibilities.png?alt=media&amp;token=1d26aa46-0e9d-4ba4-b01b-a574e2086ac2" alt=""><figcaption></figcaption></figure>

Different people take part at different stages, and each sees only what their role needs. Most organisations use these roles:

| Role                      | Typical responsibilities                                                                       |
| ------------------------- | ---------------------------------------------------------------------------------------------- |
| **Administrator**         | Configures the platform: users, groups, forms, test suites, report templates and integrations. |
| **Project Coordinator**   | Reviews requests, sets up projects, assigns testers and tracks delivery.                       |
| **Consultant (Tester)**   | Runs the testing, records findings and evidence, and retests fixes.                            |
| **Client or stakeholder** | Requests testing, views findings and reports, and records remediation.                         |

Access can be refined further per project and through [Groups](/app/modules/groups.md).

## Requesting a pentest

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2F1KO9QiLmwjcmWlEZob2h%2F04-requesting-a-pentest.png?alt=media&amp;token=149acb4c-bc78-4eed-a409-20362a7c5b5e" alt=""><figcaption></figcaption></figure>

Testing starts with a project request. This gives requesters one place to describe what they need, and reviewers a clear point to approve it. Requesters choose services from a catalogue and fill in a scoping form. Reviewers can then approve the request, reject it, or ask for more information. An approved request becomes a project automatically, with the request details already filled in.

→ [Requesting a Project](https://support.attackforge.com/app/getting-started/requesting-a-project)

## From testing to report

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2Fd0blLjuVvEZNj7pQX2EY%2F05-testing-to-report.png?alt=media&amp;token=eab3a8db-aae4-4a07-9752-d4cfeed6219c" alt=""><figcaption></figcaption></figure>

Testers record their work as they go, so the report is built from live project data rather than written from scratch at the end.

* **Test cases** guide the testing and show coverage, so you know what was tested and what is left.
* **Findings** capture each vulnerability with its severity, affected assets, evidence and recommendations. You can draw on your writeups library so the wording stays consistent.
* **Reports** are generated from that data using your own templates, so they’re ready to review as soon as testing finishes.

## Remediation and retesting

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2F8PMssNR4L9XepTDjlrcg%2F06-remediation-and-retesting.png?alt=media&amp;token=0f5c26c6-f64a-4948-bdf2-d33f4d7d8396" alt=""><figcaption></figcaption></figure>

A finding is closed when the fix has been verified, not when the report is sent. AttackForge keeps the people fixing issues and the testers checking those fixes working from the same records.

* Asset owners see the findings assigned to them and record their remediation work as notes.
* When a fix is ready, a tester retests it and either closes the finding or reopens it with new evidence.
* Every status change is tracked, which gives you a reliable history for audits and for repeat assessments.

## Humans and AI agents

<figure><img src="https://372186556-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M8s1QY2Q6YTHB4a6DMu%2Fuploads%2F7i6EV06XuOHqgQOH2vZ8%2F07-humans-and-ai-agents.png?alt=media&amp;token=8d99964d-57e3-45b0-a979-f7bf852fd75a" alt=""><figcaption></figcaption></figure>

AI agents can now take on repetitive work in AttackForge, while people stay in charge of the decisions. Through AttackForge’s [MCP](/app/modules/ai-mcp-and-skills.md) integration, an AI assistant can carry out tasks such as:

* finding projects and vulnerabilities
* drafting findings
* raising project requests
* adding notes
* [performing penetration testing and retesting](/app/ai-agentic-workflows.md)
* [vulnerability enrichment](/app/ai-agentic-workflows.md)
* [drafting executive summary](/app/ai-agentic-workflows.md)
* [attack chain analysis](/app/ai-agentic-workflows.md)

The agent works with the same permissions as the user it acts for. Everything it does goes through the platform’s normal workflows and audit trail, so a person can review it.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://support.attackforge.com/app/getting-started.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.