PyRIT memory and CoPyRIT setup for red teams

PyRIT memory and CoPyRIT setup: what to decide before the first session

A red team that keeps prompts, responses and scores in scattered notebooks will struggle to review results together, so the work is to choose a memory backend, decide how the team reaches the CoPyRIT GUI, and prove both work before any testing starts. PyRIT stores conversations and results in SQLite or Azure SQL, and CoPyRIT is the web interface that lets people run human-led sessions and collaborate on the same data. Both choices should be settled on paper before the first session.

This is harder than it looks because memory is where every prompt, response and score lands. A weak choice affects later review, reporting and handover, and it is difficult to change once a team has months of results in one store. Decide who will own the database, where it will live, how long records are kept and who can read them. Prompts and harmful outputs stored in memory are sensitive material, so the store needs the same access control as any other repository of test evidence. Ask whether the team needs a single shared store or separate stores per engagement, because that choice shapes how results are combined later.

SQLite suits a single host or a small team working from one machine, with few moving parts. Azure SQL suits teams that need a shared, centrally managed database reachable from several test hosts. Confirm the backend against the PyRIT documentation for the release you will use, and check how configuration is set in the ~/.pyrit/.pyrit_conf file and credentials in ~/.pyrit/.env. Credentials for the database and for model endpoints should not be copied between people's machines. Plan a single documented location for the configuration and a rule for who edits it.

CoPyRIT needs a deployment decision too. Decide whether it runs on a local workstation, a shared internal host or a controlled cloud environment, and how testers reach it. Confirm that it can read the same memory as the scanner and the Python framework, because a team that splits results across interfaces loses the shared review that justified the setup. Check authentication and network exposure before anyone enters a live target, and record which people can start sessions and which can only review them.

Prove both pieces before testing starts. Run a benign test prompt through a non-production target, confirm the conversation and score appear in the chosen memory, open the same record in CoPyRIT from a second tester's account, and confirm the record is readable after a restart. The setup cost is engineering and review time, not a license, because PyRIT is MIT licensed. Budget the hours for the people building the store, writing the access rules and running the proof, and ask any partner for those hours as a separate line in the written scope.

Which PyRIT parts store results and expose the team GUI

PyRIT separates where results live, how people work with them, and how runs are launched. The cards below cover the memory layer, the CoPyRIT GUI, the pyrit_scan command, the Python framework, and the two configuration files that hold credentials and settings. Read them together to decide which entry point your red team uses and where its data ends up.

PyRIT memory for conversations and results

PyRIT memory stores conversations and attack results, and the documentation names SQLite and Azure SQL as the supported backends. Every run, whichever entry point starts it, writes to this store, so it is the first thing to settle. Check which backend fits your data residency rules, and confirm how memory behaves when several people or pipelines share one database.

CoPyRIT web GUI for human-led testing

CoPyRIT is the web interface for human-led red teaming and team collaboration on top of PyRIT. Testers use it to drive attacks interactively, review responses, and share work with colleagues. Confirm which team members will have access, how sessions are authenticated in your environment, and whether the GUI runs on a shared host or on each tester's workstation.

pyrit_scan command for automated runs

The pyrit_scan command runs PyRIT as a scanner, which suits repeatable checks such as regression runs after a model or prompt change. It is the entry point for scheduled or pipeline-driven testing where no one is at a keyboard. Before adopting it, confirm which targets and scenarios it can invoke in your version, and where its output is recorded in memory.

Python framework for custom attacks

PyRIT can be used directly as a Python framework, which is how teams build custom attacks, targets, converters, and scorers. This entry point gives the most control and carries the most engineering effort, since your team owns the code. Plan for tests of custom components after each release, because the framework API is what those components depend on.

The ~/.pyrit/.env file for credentials

The ~/.pyrit/.env file holds the credentials PyRIT uses to reach model endpoints and other services. Keep it out of shared repositories and images, and restrict read access to the account that runs PyRIT. Confirm which keys your targets and scorers require, and who rotates them.

The ~/.pyrit/.pyrit_conf file for settings

The ~/.pyrit/.pyrit_conf file holds PyRIT settings that are not secrets, such as runtime behavior that the framework reads at startup. Because it changes how every run behaves, record its contents with your test configuration and review changes like code. Confirm the available settings against the documentation for the version you deploy.

SQLite or Azure SQL for PyRIT memory: which fits your team

This table compares SQLite and Azure SQL as PyRIT memory backends by team shape, operating burden and how each affects sharing through CoPyRIT. Use it to decide whether one operator on one host can keep the store local, or whether a shared store on Azure is worth running. Confirm current backend configuration details in the PyRIT documentation for your release before you commit.

Consideration	SQLite	Azure SQL
Best fit	One operator or a small group working on one host, running tests from a single machine	A team that needs one shared store for conversations and results, reachable from several workstations or hosts on Azure
Who runs the database	The operator who runs PyRIT, as a local file with no separate server to administer	Your Azure platform or data team, who provisions, patches and monitors the database service
Where access is granted	Operating system file permissions on the host holding the database file	Azure identity and network controls, such as role assignments and firewall or private network rules you define
Backups and recovery	Copying the database file on a schedule you set and store securely; the team owns restore steps	Backup and retention handled by the Azure service, with restore procedures your team should test before relying on them
Effect on CoPyRIT sharing	Results stay with the host running CoPyRIT, so sharing usually means exporting or moving data by hand	Multiple CoPyRIT users can work against the same store, which supports team review of findings
Credentials and configuration	Typically minimal; confirm the file location and settings in ~/.pyrit/.pyrit_conf for your release	Requires connection settings and secrets kept in ~/.pyrit/.env or your secret store; confirm supported authentication options in the PyRIT documentation
Stored prompts and harmful outputs	Protected by the security of the host and its disk, so host hardening and encryption matter	Protected by database access controls, audit logging and data handling rules you set for the Azure resource

How to set up PyRIT memory and CoPyRIT step by step

Follow this sequence to get a PyRIT installation that stores conversations and results in memory, serves them to a shared CoPyRIT session, and records a scanner run. Each step ends with a check you can repeat before moving on.

Confirm a supported Python version
The engineer building the test host confirms that the interpreter falls within the range the PyPI package supports, which is Python 3.10 up to but not including 3.15. The PyRIT documentation recommends Python 3.13, so use that version where your platform policy allows it. Run the interpreter version command in the environment the testers will use, and record the output in the setup notes. The step is done when the version falls within the supported range and every tester on the team uses the same version.
Install PyRIT from the microsoft/PyRIT line
Install the package with pip from PyPI, where the project is published as pyrit, into a virtual environment dedicated to red teaming. Take the source and documentation from the microsoft/PyRIT repository, since the Azure/PyRIT repository is archived and read-only. Pin the version your team will test against, and review the release notes for that version on the microsoft/PyRIT releases page before you pin it. The check is that importing the package in Python succeeds and the installed version matches the pin the team recorded.
Populate the credentials and settings files
Create the ~/.pyrit/.env file for model endpoint credentials and the ~/.pyrit/.pyrit_conf file for PyRIT settings. Use the variable and setting names shown in the documentation for your version, since names can change between releases. Restrict the file permissions to the tester's account, keep the .env file out of shared folders and version control, and avoid pasting secrets into notebooks or shell history. The check is that a short script run from the same account loads the expected target settings and reports no missing credentials, without printing any key values.
Select the memory backend and verify writes
Choose SQLite when one tester works on one host, or Azure SQL when several testers need the same store, and set the backend in the configuration file. Confirm the exact setting names in the documentation for your version. Send one test prompt through a configured target, then confirm that the conversation record appears in the database. Restart the Python process and query memory again. The check is that the stored conversation reappears after the restart, which shows that memory persists outside the session.
Launch CoPyRIT and confirm shared history
Start CoPyRIT, the web GUI for human-led red teaming and team collaboration, on the host that uses the shared memory backend. Confirm the launch command and the access controls for your release in the documentation before exposing it to other users. Open the interface from two separate browser sessions with two different accounts. Start a conversation in the first session and confirm it appears in the second session. The check is that the second user sees the same conversation list and the same messages as the first user.
Run one test through pyrit_scan
Run a single scan through pyrit_scan against one target the team is authorized to test, using a small prompt set that the red team has approved. Use the memory backend configured in the earlier step so results are written to the same store. When the run finishes, query memory for the run's conversations and scores, and compare them with the console output. The check is that the scan results and scorer outputs are stored in memory and appear in CoPyRIT under the same run.

How CoPyRIT and pyrit_scan divide the red team's work

PyRIT offers three ways into the same framework, and a red team should decide early which one handles which part of the work. The pyrit_scan command runs a scanner, which suits repeatable sweeps across a set of prompts and targets. CoPyRIT is the web GUI for human-led red teaming and team collaboration, where a tester drives a conversation, reads each response and decides what to try next. The third path is the Python framework itself, which the team uses to build custom attacks, converters and scorers when neither the scanner nor the GUI fits. These are not competing products. They are three front doors to the same targets, attacks, scorers and memory.

The practical consequence is that all three write to one memory store. PyRIT memory keeps conversations and results in either SQLite or Azure SQL, so a finding produced by a scan can be opened in CoPyRIT, and a conversation started by a tester can be reviewed later by someone who never saw it live. Before the team relies on this, it should confirm which memory backend each tool points to, that every person and job reads the same database, and where credentials and settings are loaded from, since PyRIT reads them from ~/.pyrit/.env and ~/.pyrit/.pyrit_conf. A scan running under one user profile and a GUI session under another can quietly produce two disconnected stores.

An illustrative workflow shows how the split can work. A scheduled pyrit_scan run exercises a chat target with a standard prompt set and a content-harm scorer, then records every conversation in shared memory. The scorer flags a small number of responses as possibly unsafe. A reviewer opens those entries in CoPyRIT, reads the full exchange, and continues the promising ones by hand, changing wording and trying multi-turn strategies such as Crescendo where the scan only ran single prompts. Conversations the reviewer rejects stay in memory with a note, so the next scan does not repeat the same dead ends. The reviewer, not the scorer, decides what becomes a finding.

The workflow only holds if the handoff is controlled. Decide who may start scans, who may continue conversations in CoPyRIT, and who signs off a finding. Agree how reviewer notes are recorded so they survive the next run. Test the handoff with a dummy target before the first real engagement, because a scan that writes to a different database than the GUI reads will fail without an obvious error. Check the PyRIT version on each machine as well, since the team should confirm the release line used for both tools before comparing results across them.

How memory and CoPyRIT change on a laptop, shared host or locked-down network

On a single operator's workstation, PyRIT and CoPyRIT run inside one user's Python environment, and memory lives wherever that user can write. SQLite is the simplest option here because it needs no separate database service. Credentials sit in the operator's ~/.pyrit/.env file and settings in ~/.pyrit/.pyrit_conf, so the laptop holds everything needed to run an attack. Teammates cannot see this memory unless the operator copies or exports it, so shared review happens after the work is complete.

Memory location: the SQLite database sits on the local disk. Confirm its path in the PyRIT configuration and where backups are stored.
Credentials: keys in the .env file are readable by any process running as that user. Confirm disk encryption and screen lock policy.
CoPyRIT access: the GUI opens in a local browser. Teammates can join only if the operator deliberately exposes the service, which should be a recorded decision.
Network path: confirm the laptop can reach each model endpoint through the corporate VPN or proxy, and that pip can fetch packages.
Results handover: agree how findings leave the laptop, through an approved export, and who keeps the authoritative copy.

Before the first test, check where the database file lives, who else can read the user profile, and whether this laptop is permitted to send prompts to the target models.

What drives the effort of a shared PyRIT memory setup

This table lists the factors that change how much work a shared PyRIT memory and CoPyRIT setup takes, and how to keep each one manageable. Read it before agreeing on a backend and environment plan, because the first two drivers are usually the ones that expand scope fastest. The main takeaway is that one agreed memory backend and one shared configuration template remove most of the avoidable effort.

Driver	Why it changes effort	How to keep it down
Red team members using CoPyRIT	Each added user adds accounts, access rules, shared-session handling and more concurrent writes to the same memory store.	Agree the number of named users up front, and confirm with the CoPyRIT documentation how team collaboration is configured before onboarding more people.
Volume of stored conversations and results	Large histories increase storage growth, query time, backup scope and the work needed to review and export findings.	Set a retention rule for test runs, tag runs by campaign, and archive closed campaigns instead of keeping every prompt indefinitely.
Target types with consistent response storage	Each target type (OpenAI, Azure, custom HTTP or WebSocket, Playwright web apps) can return responses in different shapes that must be recorded the same way.	Limit the first phase to the target types in scope, and write one storage convention per target type before testing starts.
Memory backend: SQLite or Azure SQL	SQLite is simpler for a single host, but shared access from several machines needs a database both can reach. Azure SQL adds cloud resources, network rules and access management.	Choose one backend for the whole team and document it. Confirm with the PyRIT documentation which backend fits your hosting model before building anything.
Environment count: laptop, shared host, restricted network	Each environment has its own Python version, credentials file, network route and memory location, so the same setup must be rebuilt and checked in each.	Keep to the fewest environments that meet the test need, and maintain one shared configuration template for ~/.pyrit/.env and ~/.pyrit/.pyrit_conf.
Reviewer workflows	Reviewers need to find, score and sign off stored results, which adds roles, review states and a process for disputed findings.	Define the review steps, the reviewer roles and the evidence each finding needs before the first campaign, and keep the workflow in a written procedure.

How to confirm PyRIT memory persists and CoPyRIT shows the same results

Before any red team relies on PyRIT results, confirm that the memory layer keeps them and that CoPyRIT reads the same records. Run these checks on a test host with a disposable target before you point the setup at a system under evaluation. Start by recording the exact PyRIT version under test. PyRIT v1.1.0 was released on 4 September 2026, and later releases may change how memory, scanning or the GUI behave, so a check that passes on one version is only evidence for that version. Write the version, the Python interpreter, the installed package source and the date of the run into your test log.

Next, confirm that the memory backend is the one you intended. PyRIT memory stores conversations and results in either SQLite or Azure SQL, and the choice determines where records live, who can reach them and how they survive a host rebuild. Read the active configuration from ~/.pyrit/.pyrit_conf and the credentials from ~/.pyrit/.env, then run a short attack or scan and check that the record appears in the database you expected. For SQLite, confirm the file path and its ownership. For Azure SQL, confirm the server and database names. A run that quietly fell back to a local default store is a finding in its own right, because the results will not appear where your team looks for them.

Then test persistence. Create a conversation through a simple scan, stop every PyRIT process, restart the host or the session, and query the same memory for that conversation ID. Confirm that the prompts, responses and scorer outputs are all present and unchanged. Repeat the check after a clean reinstall of the Python environment that points at the same store, because red teams often rebuild tooling without rebuilding data. If records disappear after either step, stop and fix the storage path before any further testing.

Next, test the team view. Open CoPyRIT with a second user account or a second browser profile on another machine that reaches the same memory store, and confirm that it lists the same conversations, scores and attack runs that the first user created. Then start a scan from the command line and confirm that its results appear in the GUI without manual import. Finally, test failure. Deliberately corrupt one credential value in ~/.pyrit/.env, run a scan, and confirm that PyRIT stops with a clear error that names the failing setting. A run that reports success while writing nothing, or that drops results silently, must be treated as a blocking defect. Keep the broken-credential test in your runbook so each upgrade repeats it.

What to back up, monitor and document after PyRIT memory goes live

Once PyRIT memory and CoPyRIT are in use, the red team's results live in one store and one host. The four areas below keep that store recoverable, the host visible, the configuration understood and every PyRIT version traceable to the findings it produced.

Back up and test the memory store

PyRIT memory holds conversations and results in either a SQLite file or an Azure SQL database, so the backup method depends on which one the team chose. For a SQLite file, schedule copies while no attack run is writing, and for Azure SQL, confirm the backup and retention settings with the database owner. Restore a copy to a separate host at least once and confirm that a team member can open past campaigns and their scores.

Monitor memory and the CoPyRIT host

Track whether the memory store accepts reads and writes, whether the disk holding a SQLite file has room to grow, and whether the CoPyRIT web service responds for each team member. Alerts should reach the people who run red team campaigns, not only infrastructure on-call. Check after each scheduled run that results were written, since a silent failure can leave a campaign looking complete when it is not.

Document the configuration template and its owner

Each PyRIT setup depends on settings in the ~/.pyrit/.pyrit_conf file and on credentials in ~/.pyrit/.env, so teams should keep a reviewed template that lists every setting, its purpose and its default. Name one owner who approves changes to the template and records who holds each credential. Keep credential values out of the template itself, and store the template in version control alongside the team's runbook.

Record PyRIT version changes per upgrade

PyRIT releases change targets, converters, scorers and memory behavior, so a finding is only reproducible if the team knows which version produced it. Keep a change record for each upgrade that lists the old and new version, the date, the Python version used (the documentation recommends Python 3.13), and the custom attacks and scorers retested. Link each campaign record to the version that ran it.

Control access to stored prompts and outputs

Memory contains the prompts that were sent to tested systems and the harmful outputs they produced, so it must be treated as sensitive data. Limit read access to named red team members, log who opens or exports records, and set a rule for how long results are kept and how they are deleted. The separate PyRIT security hardening guidance covers how to implement these controls, so follow it for the detailed steps rather than building them from this list.

What do teams ask before setting up PyRIT memory and CoPyRIT?

Is SQLite enough for a small PyRIT red team?

For many small teams, yes. PyRIT memory can store conversations and results in SQLite, which needs no separate database service and is quick to set up on a single test host.

The deciding questions are practical. Does more than one person need to write results at the same time? Where does the database file sit on disk, who backs it up, and who can open it? Could someone who should not see harmful outputs read the file?

If one operator works at a time and the file stays on a controlled host, SQLite is usually the simpler choice. If the team shares results across machines or needs central retention and access controls, evaluate Azure SQL. Confirm the choice against your own workflow before the first test run.

When is Azure SQL worth the extra operational effort?

Azure SQL is worth considering when results must be shared across several machines, kept under central retention rules, or governed with the Azure controls your security team already uses for other sensitive data. PyRIT memory supports both SQLite and Azure SQL, so the decision mostly concerns how the store is run.

The extra effort includes provisioning the database, setting network rules and firewall access, managing identities, planning backups and restores, and deciding who administers it. Connection details belong in the PyRIT credential file, which then needs the same protection as any other secret.

Ask for these items in a written scope, and confirm whether your Azure subscription, networking and identity setup already support them.

Can our team set up PyRIT memory without a partner?

Yes, if your team has Python engineers who can install and pin the package, read the configuration documentation, and own the test hosts and storage. PyRIT installs with pip, reads credentials from a file in the user's home directory and settings from a second file there, and CoPyRIT runs as a web GUI for human-led red teaming.

The work gets harder when the team must decide retention periods, access lists, network isolation for Azure SQL, or how several operators share one store. Those decisions need written owners and documentation, and they must be repeatable across hosts.

If you want outside help, ask for a written scope that lists which decisions the partner makes with you and which your team keeps.

What does the setup need from our team beforehand?

Three things must be ready: a Python environment, Azure access if you choose Azure SQL, and a named owner for the store and its access list.

Python environment: PyRIT's PyPI package supports Python 3.10 up to but not including 3.15, and the documentation recommends Python 3.13. Confirm your hosts can run that version under your change control.
Azure access: a subscription, a resource group, network rules and an identity that can create or use the database.
Named owner: a person who approves who can read stored prompts and harmful outputs, sets retention, and handles access requests after handover.

Without a named owner, shared credentials tend to appear and nobody reviews the access list.

How long does PyRIT memory setup take for our scope?

The duration depends on scope, and no fixed figure applies until the scope is written. The main drivers are the number of hosts, whether the store is SQLite or Azure SQL, how many people will use CoPyRIT, how many targets and custom endpoints must be connected, and whether access control and backup need design work or only a standard pattern.

A single-host SQLite setup for one operator is the smallest case. Azure SQL with network isolation, several operators and documented access rules is a larger piece of work.

Ask for a fixed-scope proposal that lists each deliverable, the dates it depends on, and what your team must provide and when. Most engagements are fixed-scope and agreed in writing before work starts.

What makes PyRIT memory and CoPyRIT setup cost more?

Cost comes mainly from the people doing the work and from the decisions that need them. PyRIT is MIT licensed, so the software itself carries no license fee.

One-time setup: engineering time for installation and configuration, the storage option, Azure work if you use Azure SQL, access control design, documentation, and training for CoPyRIT users.
Recurring costs: model API calls made by attacks and scorers, storage that grows with retained results, and reviewer time spent on findings.

Ask any quote to separate one-time setup from recurring items and to state which costs your team pays directly, such as model and Azure spend.

Who should own the PyRIT results store after handover?

A named person or role should own it, with a named backup. Ownership covers the access list, retention decisions, backup and restore checks, credential rotation, and approval of new CoPyRIT users.

Results include harmful model outputs, so the owner should work with security and data protection staff to decide who can read them. Record the owner in the handover documentation and in the team runbook.

Confirm that the owner holds the host or Azure permissions the job needs, so access decisions can be carried out without waiting on someone else.

What usually goes wrong in a shared PyRIT memory setup?

Configuration drift is the most common problem. Different hosts may run different PyRIT versions or Python interpreters, so scripts and results can behave differently between operators.

Credentials placed in the wrong file, copied between hosts, or left with broad permissions create avoidable exposure. SQLite file locations and permissions also vary between machines, so one operator may write to a copy that others never see. Azure SQL setups often fail on network rules, firewall settings or identities that lack the right database permissions.

Teams also forget retention, so harmful outputs accumulate with no review. Test the shared store with two operators before the team relies on it.

How DeployOpen scopes, builds and hands over PyRIT memory and CoPyRIT setups

DeployOpen plans and implements PyRIT memory and CoPyRIT setups for red teams inside the client's own infrastructure, from the storage choice through to a working shared environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

The written scope names the targets, attack strategies and scorers the red team will use with PyRIT.
We record whether memory runs on SQLite or Azure SQL and who needs access to stored results.
Scope states which team members will use CoPyRIT and which workflows stay on the pyrit_scan or Python framework paths.

How we build

We install PyRIT in a pinned Python environment, using the Python version the documentation recommends and checking it against the supported range.
We configure credentials in ~/.pyrit/.env and settings in ~/.pyrit/.pyrit_conf, and keep secrets out of shared repositories.
We test memory storage, target connections and CoPyRIT access on a test host before any shared red teaming use.

How we hand over

You receive the configured environment, a record of the memory backend choice and the access model used for stored prompts and outputs.
Documentation covers how to start CoPyRIT, add a team member, export results and run a basic attack from start to finish.
We walk your red team through a sample session and record open items that need your confirmation in your own environment.

How we support

Ongoing support is available as a retainer for keeping the memory setup and CoPyRIT configuration working after handover.
We can revalidate custom targets, converters and scorers when you move to a new PyRIT release, such as the 1.x line.
Support covers troubleshooting shared access and storage issues, with the scope of each request agreed in writing.