What PyRIT cost of ownership covers and who pays for it
PyRIT itself has no license fee. It is MIT licensed under Microsoft's open source project, so the money you spend keeps going to the parts around it: model calls for attacks and scoring, the infrastructure that runs the tests, engineering time to build and maintain red teaming scenarios, storage for conversations and results, and the people who read and triage what the framework finds. Those are the costs that recur, and they are the ones a budget owner needs to see before approving a rollout. A cost review is usually triggered by one of three situations. The first is budget approval, when finance or the CISO asks for a line item beyond a one-time install. The second is the first AI system a team tests, where the cost of attack and scoring calls is still a guess. The third is moving from a pilot to a standing program, where a one-off exercise becomes a schedule that runs every release and every time a model or prompt changes. Each of these shifts the question from "can we install it" to "who pays every month to keep it useful." Most teams carry the core cost in-house: the model accounts, the test hosts and the staff who review outputs. Many hand part of the work to a partner, most often the initial build of reusable scenarios, the validation of custom targets, converters and scorers, and the periodic upgrades after each release. The split depends on how many systems you test, how often, and whether you have people with the time and skill to judge harmful outputs consistently. When you ask for a quote or build an internal estimate, separate one-time work (scoping, first scenario build, integration with your targets and storage) from recurring work (model spend per test cycle, storage growth, upgrades, reviewer hours). For model spend, ask the vendor for the current per-token rates of each model you plan to call, and confirm how many attack turns and scorer calls a typical test cycle produces in your own environment. Those two inputs usually explain most of the variance between estimates.
Confirm the points that depend on your environment rather than on the framework. Check which model providers you will call and under what agreements, since those terms set your spend and data handling. Check where memory will live, whether SQLite on a test host or Azure SQL, because that choice determines backup, access control and storage cost. Check who owns the reviewer role for harmful outputs and how many hours per cycle that review takes. These are the figures that decide total ownership cost, and none of them are fixed by the license.
What the cost-of-ownership work includes and what you receive
The cost-of-ownership review is a fixed-scope piece of work that starts from a written inventory of your PyRIT environment and ends with a recurring cost model, a named owner for every cost line and handover notes your team can run without us. Each deliverable below is tied to a specific item you can check against your own environment.
Environment inventory
We record every PyRIT component in use: targets, converters, scorers, attack strategies, memory, datasets, any pyrit_scan runs and CoPyRIT if you deployed it. The inventory names the owning team, the version and the environment for each item. It is the base for every cost line, because a target you forgot to list usually carries the largest model bill. Check that the list includes scheduled jobs and developer laptops.
Usage and call-volume baseline
We measure how often each target, attack and scorer runs over a period you choose, using logs, provider usage reports and PyRIT memory records. The baseline separates attack traffic from scoring traffic, because the two often use different models at different prices. Ask whether your provider exposes per-deployment usage, since that determines how precisely the baseline can be split.
Recurring cost model
The cost model is a spreadsheet that lists each recurring cost by component: model calls for attacks, model calls for scoring, Azure AI Content Safety or other scorer services, result storage in SQLite or Azure SQL, hosting for test runners, and reviewer time. Each line carries a unit, a volume driver and a rate you supply from your contracts. Ask for the formulas to be left editable so finance can change assumptions.
Cost line owner register
We write down who pays for and who answers for each cost line, including the billing account, the technical owner and the person who approves spend above an agreed threshold. Ownership gaps are the most common reason PyRIT costs grow unnoticed, for example when a scenario written by one researcher keeps running after that person moves teams. Confirm each named owner accepts the role in writing.
Upgrade and revalidation calendar
The calendar lists when each PyRIT release is reviewed, which custom targets, converters and scorers need retesting, and who does the retest. PyRIT moves quickly, and its 1.x line includes v1.1.0, so retesting effort recurs with each upgrade. Check that the calendar sets the revalidation effort as its own cost line rather than hiding it inside general maintenance.
Handover notes
The handover notes explain how to run, review and cost the environment without our involvement. They cover credential locations in ~/.pyrit/.env, configuration in ~/.pyrit/.pyrit_conf, how to read the usage baseline, and the steps to update the cost model. Ask for a short walkthrough with the people who will own each cost line, and for the notes to be stored where your red team can find them.
What drives PyRIT running costs up or down
This table lists the main drivers of PyRIT running costs and effort, with the reason each one moves spend and one practical way to hold it down. Read each row as a lever you control during planning. Model and scorer pricing is set by each provider, so confirm rates with them before estimating spend.
| Driver | Why it moves cost | How to hold it down |
|---|---|---|
| Number of targets | Each provider, HTTP or WebSocket endpoint, and Playwright-driven web app adds credentials, configuration and test runs. | Start with the targets in your threat model and add others only when scope requires them. |
| Multi-turn attack volume | Crescendo, TAP and Skeleton Key make many model calls per objective, so spend grows with turns and branches. | Cap turns and branches per objective and rerun only failed or changed scenarios. |
| Scorer choice | LLM-based scorers add model calls for every response, while Azure AI Content Safety and custom logic bill separately. | Run deterministic custom checks first and reserve LLM scoring for ambiguous outputs. |
| Memory backend | SQLite runs on the test host with no extra service, while Azure SQL adds a database to provision, patch and pay for. | Keep SQLite for single-team work and move to Azure SQL only when shared access requires it. |
| Testers using CoPyRIT | Each shared user adds access control, review time and hosting load on the CoPyRIT GUI. | Assign roles, schedule batched review sessions and check hosting needs before adding users. |
| Retention of conversations and outputs | Stored prompts and harmful outputs grow storage, backup and access review effort for as long as they are kept. | Set a written retention period and purge outputs that no finding or evidence record cites. |
| Number of environments | Each environment needs its own configuration, credentials and validation runs after every change. | Keep one parameterized configuration and promote tested scenarios between environments. |
| Compliance evidence retained | Assessors may ask for test plans, run logs and remediation records that must stay complete and reproducible. | Agree the evidence list with your assessor early and store it with versioned run metadata. |
Which costs recur after PyRIT goes live
Most of the money spent on PyRIT happens after the first working setup, and the licence is not where it goes. PyRIT is MIT licensed, so there is no license fee and no paid edition to choose. Any subscription spend comes from the cloud services and model providers you connect to it, and from the people who keep the work running. Before you sign a quote, separate the one-time setup from the lines that continue every month, because the recurring lines are the ones that decide total ownership cost. One-time costs cover initial configuration of the framework, the first set of target connections, and validation of any custom targets, converters and scorers your team writes. Validation of custom components is a one-time cost only until the next release changes something they depend on. Ask the partner to name which items are delivered as a fixed piece of work and which are estimated against your environment, and to confirm what is handed over as documentation at the end. Recurring costs include model API calls for attacks and for LLM-based scoring, compute and storage for the host that runs PyRIT, and the memory database that holds conversations and results, whether SQLite or Azure SQL. Model calls usually scale with the number of attack turns and scoring passes, so a multi-turn strategy such as Crescendo, TAP or Skeleton Key costs more per objective than a single prompt run. Storage grows with every stored conversation, so set a retention rule early. Engineering time recurs with each PyRIT release on the 1.x line. PyRIT v1.1.0 was released on 4 September 2026, and each later release needs a review of your pinned dependencies and custom code. Revalidation of custom targets, converters and scorers after upgrades is the line most often missed in budgets. A change to a target interface or scorer output can silently break a test suite that still appears to run. Security upkeep is also recurring: credentials in ~/.pyrit/.env must be rotated and access to test hosts reviewed, and reviewer hours for triaging results repeat for every test cycle. Ask the partner to show, per line, whether it is fixed, pass-through at your provider's rates, or billed on time, and who owns each line after handover, your team or theirs.
How a PyRIT cost review moves from baseline to handover
The sequence runs from a baseline of the environment to a handover that names an owner for every cost line. Each phase produces a written artifact that the next phase depends on. Timing depends on how many environments and targets are in scope, and the written scope sets the schedule.
Inventory the environment and Python runtime
Confirm where PyRIT runs and what surrounds it: the hosts or cloud accounts, the model and API targets, the SQLite or Azure SQL memory store, and any CoPyRIT instances or scheduled scan jobs. Record the Python version in use. The PyPI package supports Python 3.10 up to but not including 3.15, and the PyRIT documentation recommends Python 3.13, so note any gap between the installed version and the recommendation. The output is a baseline inventory listing each component, its owner and its current version. The step is done when the client confirms that nothing in active use is missing from the list.
Measure usage over a representative test period
Run the team's normal red teaming workflow over an agreed test period and log the activity PyRIT produces. Record the model calls made by attacks and by scorers, the targets reached, the multi-turn strategies used (such as Crescendo, TAP or Skeleton Key), and how fast stored conversations and results grow. Agree the period with the client so it reflects a typical attack campaign, and label any quiet days or unusual runs. The output is a usage log split by target, attack type and scorer, with the assumptions about the period written down. The step is done when the client agrees the period is representative.
Build the cost model with unit assumptions
List every cost component and who pays for it: model API spend for attacks and scorers, Azure AI Content Safety charges if that scorer is used, storage for memory and results, compute for hosts, engineering time, and reviewer time. Mark each line as one-time or recurring. Attach a unit assumption to each line, such as cost per call or cost per gigabyte per month, and take the unit prices from the provider's current published price list at the time of the review. Ask the client to confirm which contracts and discounts apply. The output is a cost model in which every unit has a stated source. The step is done when the client has checked each unit against its source.
Review the reviewer workload
Estimate how much human review the usage produces. Count the findings each run generates, the scorer flags that need a person to read them, and the share that turn out to be false positives on a sampled set. Record who reviews, how long a review takes in their own terms, and whether CoPyRIT is used to share review work across the team. Reviewer time is often the largest cost that is not on an invoice, so keep it as a separate line. The output is a workload estimate per test cycle with the sampling method documented. The step is done when the reviewers confirm the estimate matches how they work.
Write recommendations for each cost driver
Turn the model and workload findings into written recommendations. Typical items include the choice of scorers, how many attacks run per cycle, which targets need full coverage and which need a smaller set, the retention period for stored prompts and outputs, the Python version the team standardizes on, and whether memory is consolidated. For each item, state the trade-off, the effect on the cost model and the risk it carries for test coverage. Rank the items by expected effect. The output is a recommendations document with one entry per cost driver. The step is done when the client accepts, changes or rejects each item in writing.
Hand over with an owner for each cost line
Walk the client through the final cost model and the accepted recommendations. Assign a named owner to each cost line, including model spend, storage, hosts, engineering effort and reviewer time, and agree how often each owner reviews their line. Add the points that change the model, such as a new PyRIT release, a new target or a change in the Python version. The output is a handover pack containing the model, the recommendations and a signed owner table. The step is done when every cost line has an owner who has accepted it.
Which PyRIT cost work your team keeps and which a partner can carry
This table separates the PyRIT cost of ownership work that usually stays with your team from the work a partner can take on, and names the skills each part needs. Read each row as a question of who should hold the decision, who should do the labor, and who must be trained to handle the output. The main takeaway is that the judgment calls and the review of harmful content should stay with accountable staff, while modeling, instrumentation, storage setup and upkeep planning are often carried by an outside team.
| Cost work | Usually kept in-house | Often outsourced | Skills required |
|---|---|---|---|
| Owning the test program | Yes: sets risk appetite, priorities and sign-off for AI red teaming | No: a partner can advise but should not own program decisions | AI red teaming judgment, risk management, accountable executive sponsorship |
| Deciding what to test | Yes: chooses targets, harm categories and acceptable test boundaries | Partly: a partner can propose a scope for your approval | Knowledge of your AI systems and data, threat modeling, AI red teaming judgment |
| Reviewing harmful outputs | Yes: reviewers must have authority and training to handle harmful content | No: keep review with named staff who have wellbeing support and escalation paths | Content harm assessment, security review, documented handling procedures |
| Approving model and API spend | Yes: budget owner approves attack and scoring volume against limits | No: a partner can estimate usage but cannot authorize spend | Cloud billing, finance controls, vendor contract knowledge |
| Building the cost model | Review only: confirm assumptions match your model providers and test plan | Yes: a partner can build the model from attack counts, scorer calls and storage | Python, cloud billing, usage forecasting |
| Instrumenting usage | Review only: confirm which metrics your finance team needs | Yes: a partner can add logging of calls, tokens and run durations to PyRIT workflows | Python, observability tooling, cloud billing exports |
| Setting up storage and retention | Yes for policy: define how long prompts and outputs are kept and who can access them | Yes for build: SQLite or Azure SQL setup, access controls and backups | Data retention policy, database administration, access control design |
| Documenting the upkeep calendar | Yes for approval: confirm release review and revalidation timing | Yes for drafting: a partner can write the calendar and runbooks for your team | Release management, technical writing, familiarity with PyRIT releases |
What usually makes PyRIT running costs grow faster than planned
PyRIT is MIT licensed, so most running costs come from model calls, stored results and the people who review them. The cards below describe where these costs usually grow without a plan, with one prevention step for each.
Unbounded attack runs against paid models
Each attack turn sends a request to the target model, so multi-turn strategies such as Crescendo, TAP and Skeleton Key multiply model spend quickly. Teams often start a run without a cap on turns, objectives or retries, and the bill only becomes visible later. Prevention: set explicit limits on turns, objectives and retries for each campaign, and create a spend alert on the model account before the first run. Check these limits in the run configuration before every scheduled test.
Scorers that call an LLM every time
An LLM-based scorer adds a second model call for each response an attack produces, so scoring spend can exceed attack spend. PyRIT also supports Azure AI Content Safety and custom logic scorers, which can handle clear-cut cases without a model call per response. Prevention: run deterministic or content safety scorers first, and send only uncertain or flagged responses to an LLM judge. Sample some clear results to confirm the cheaper scorer still agrees with the judge.
Conversation storage without a retention rule
PyRIT memory keeps conversations and results in SQLite or Azure SQL, and every campaign adds prompts, responses and harmful outputs. Without a retention rule, storage grows quietly, and the stored material becomes a data handling problem as well as a cost. Prevention: define how long raw conversations are kept, export confirmed findings to your reporting system, and purge or archive memory on a fixed schedule. Confirm storage pricing with your database or disk provider before choosing the backend.
Archived repository used as a dependency
The original Azure/PyRIT repository was archived on 27 March 2026 and is read-only, so it receives no new fixes. Forks, pinned dependencies and internal tooling that still point to it drift from the maintained microsoft/PyRIT project, and upgrade work grows with each release. Prevention: repoint dependencies to microsoft/PyRIT, install a pinned version from PyPI, and search internal code for Azure/PyRIT references. Report vulnerabilities in PyRIT itself privately through the Microsoft Security Response Center under the project's security policy.
Upgrade work on custom targets and converters
Custom HTTP, WebSocket or Playwright targets and custom converters depend on interfaces that can change between releases, such as v1.1.0, released on 4 September 2026. Each unplanned upgrade then becomes engineering work performed during a test window, when the team needs to be running campaigns. Prevention: keep a regression set of recorded inputs and expected outcomes for every custom component, and run it before adopting a new release. Name an upgrade owner for each custom component and agree the expected effort per release.
Reviewer time nobody owns
Attack runs and scorers produce findings that a person must confirm, and this review is often the largest recurring cost, even though it does not appear on a model invoice. When nobody owns triage, findings queue up and reviewers repeat the same checks. Prevention: name a triage owner, define severity levels and a review queue, and budget reviewer hours alongside model spend. Record reviewer hours per campaign for the first few cycles so future plans rest on measured figures.
How PyRIT cost of ownership changes by starting point
Teams that already hold an Azure subscription can reuse billing, identity, networking and key management for PyRIT. The cost shift is from building infrastructure to operating metered services. Azure SQL and Azure AI Content Safety appear on the team's existing bill, and spend concentrates in storage, scorer calls and reviewer time.
- Azure SQL memory: Cost grows with the number of stored conversations and the retention period. Confirm the service tier, backup settings and who pays for the instance with your Azure administrator.
- Azure AI Content Safety scoring: Each scored response can be a billable call. Confirm the pricing model, regional availability and quota with your Azure account team before scoring volumes are planned.
- Model deployments for attacks: Azure-hosted model deployments add to the existing Azure AI spend line. Confirm deployment names, quotas and which cost center they charge.
- Shared platform work: Landing zone, monitoring and key vault already exist, so setup effort shrinks. Ask whether the platform team will own the Azure SQL instance after handover.
Check which subscription and resource group PyRIT costs will be charged to, and whether a cost allocation tag is required by your finance process.
Teams that run models only through OpenAI or other hosted APIs have no model infrastructure to operate, so most cost is per call. Fixed cost stays low when memory is SQLite on a single machine. The trade-off is that data handling moves onto individual workstations, and the cost of controlling that data is easy to miss in the first budget.
- Attack and scoring calls: Multi-turn strategies such as Crescendo, TAP and Skeleton Key send many requests per objective, so model spend scales with attack breadth and turn count.
- Provider rate limits: Throttling lengthens test runs more than it adds a line item. Confirm the limits for each model on your account before scheduling large campaigns.
- SQLite memory: Adds little fixed cost, but results remain on each machine unless the team builds a sharing step. Confirm who holds the only copy of findings.
- Provider data terms: Prompts that contain harmful test content are sent to the provider. Confirm retention, logging and data-use terms in writing for the account and model you use.
Ask each provider which data-retention options apply to your account and whether test traffic is excluded from model training by default.
When models or endpoints sit inside a private network and traffic must stay local, per-call API spend may fall while fixed infrastructure cost rises. The team must run or fund compute for local models, the network path to every target, and access for the PyRIT host. Much of the first-year effort goes to approvals and network changes, not to code.
- Local model hosting: GPU or compute capacity becomes a fixed, recurring cost. Confirm sizing and hosting costs with the infrastructure team before choosing local scorers.
- Custom HTTP or WebSocket targets: Building the target adapter is one-time engineering work. Each change to the endpoint's interface later adds rework and retesting.
- Egress and access approvals: Allowing the PyRIT host to reach internal endpoints requires firewall and proxy changes. Confirm the change process and its lead time with the network team.
- Scorer reachability: LLM scorers hosted inside the network avoid external calls, but they need their own capacity. Azure AI Content Safety may not be reachable from an isolated network, so confirm access first.
Confirm with the network team that the PyRIT host can reach every target and scorer without an outbound internet path, and who approves future changes to those routes.
A fork of the archived Azure/PyRIT repository carries costs that teams starting fresh do not see. The original repository was archived on 27 March 2026 and is read-only, so upstream fixes stop flowing into the fork. Migration work is one-time, but keeping an unmigrated fork in service adds recurring risk and maintenance time.
- Migration engineering: Porting the fork, pinned dependencies and internal tooling to microsoft/PyRIT and the 1.x release line is one-time work. Estimate it from the size of the custom code, not from the size of the fork.
- Retesting custom components: Every custom converter, scorer and target needs verification against the new release. Plan test time for each component and record the results.
- Patch ownership: Because the archived repository is read-only, security fixes will not appear in the fork without someone applying them. Confirm who owns patching and how fast it must happen.
- Python runtime: The PyPI package supports Python 3.10 up to but not including 3.15, and the documentation recommends 3.13. Confirm the interpreter version in each environment before migration starts.
Ask the current fork owners to name the person responsible for each internal patch and to list every custom component that needs retesting.
CoPyRIT is the web GUI for human-led red teaming and team collaboration. With several reviewers, cost moves toward shared memory, hosting for the GUI, access control and reviewer time. For many teams the largest recurring cost is the people who review harmful outputs, not the model calls that produced them.
- Reviewer time: Reviewing outputs is recurring labor that grows with the number of findings and reviewers. Agree on expected review hours per reviewer with the test lead before setting the schedule.
- Shared memory: Several users need one results store. Azure SQL is a metered service on the team's bill, while SQLite is a local file, so confirm whether your setup supports multi-user access before choosing it.
- Hosting and access control: The GUI needs a host, transport encryption and user authentication. These add recurring operations work for patching, certificates and account management.
- Reviewer onboarding: Reviewers need guidance on the harm datasets, handling procedures and escalation paths. Confirm whether this training is included in the implementation scope or paid separately.
Confirm how many reviewers will be active at the same time and whether the GUI host and results database will sit inside the team's existing identity and access controls.
What your team must provide before a PyRIT cost review
A PyRIT cost review is only as accurate as the inputs behind it. Before any estimate is built, your team should gather the access, billing history, inventory and decisions described here. Most of these items already exist somewhere in your organization, so the main work is finding the right people and agreeing on who signs off. Start with read access to the environments where PyRIT runs or will run, including the test hosts and any shared workstations. Alongside access, the reviewer needs the PyRIT configuration files: the credentials file at ~/.pyrit/.env and the settings file at ~/.pyrit/.pyrit_conf. Secrets should be excluded from the review. Ask the platform or security team to supply copies with API keys, tokens and connection strings removed or masked, and confirm which values are secrets before anything is shared. The settings file shows which model endpoints, memory backend and defaults are in use, which drives much of the spend analysis.
Next, provide the model provider billing exports or invoices for the last test period. These usually come from the finance team, the cloud account owner or the procurement contact for each model provider in use. The reviewer needs them to separate spend on attack generation, response scoring and any other calls, because those cost lines grow in different ways. If several teams share one account, ask finance to tag or split the charges by project. Without this data, any cost figure is a guess, so confirm early that the exports cover the same dates as the test runs you want to compare. The review also needs the list of targets and the attack and scorer types in use. The red team lead or the AI product owner typically provides this list. Each target, such as an OpenAI, Azure, Anthropic or Google model, a custom HTTP or WebSocket endpoint, or a web app driven through Playwright, carries its own call pattern and cost. Multi-turn strategies such as Crescendo, TAP and Skeleton Key make many more model calls than single-turn runs, and LLM-based scorers add calls of their own. Record which scorers are LLM-based, which use Azure AI Content Safety and which use custom logic, because each choice changes the bill.
Retention requirements come from legal, compliance or the data protection office. PyRIT memory stores conversations and results in SQLite or Azure SQL, and the harmful outputs produced during testing may be sensitive. How long those records must be kept, and where, determines storage size, backup scope and deletion effort. Ask for a written retention period for prompts, responses and scores, plus any legal hold rules that apply to AI testing evidence. Storage cost grows with retention, so a short, clear answer keeps the estimate honest. Two roles are often missed. First, name the people who review findings and state how much time each can give per week during the engagement. Human review of flagged outputs is frequently the largest unplanned cost, because it depends on people's calendars rather than on any invoice. Second, name a decision owner for spend. This person approves model budget increases, accepts the trade-off between test coverage and cost, and resolves disagreements between security, engineering and finance. Without a named owner, the review will produce numbers that nobody is accountable for acting on. Confirm these items before the review starts: environment access, sanitized configuration files, billing exports for the same period, the target and strategy inventory, retention rules, reviewer names with weekly time, and one accountable spend owner.
PyRIT cost of ownership questions buyers ask before hiring help
Does PyRIT have a license cost?
No. PyRIT is open source under the MIT license, and there is no paid edition to buy. The license itself costs nothing, so your spend comes from the work around it: model API calls used for attacks and scoring, compute and storage for results, engineering time to build and maintain scenarios, and the people who review findings. Confirm the license text in the microsoft/PyRIT repository before you rely on it in your procurement file, and check the license of any third-party target, converter or scorer you add.
What drives the monthly running cost of PyRIT?
Four things drive it. Model API calls are usually the largest variable, since every attack turn and every LLM-based scorer call is billed by your provider. Compute depends on where you run the scanner and how many test runs execute in parallel. Storage covers the memory database that keeps conversations and results, whether SQLite on a local host or Azure SQL. People time covers triage of findings, retesting after changes and upkeep of custom code. Ask a partner to separate one-time build costs from these recurring costs in any written quote.
Is model API spend the largest cost line for PyRIT?
It often is, but it depends on your setup, so measure it in your own environment rather than assume it. Spend rises with the number of targets, the number of attack strategies run against each target, the number of multi-turn conversations, and the scorers you choose. An LLM-based scorer adds calls on top of the attack traffic, while a non-LLM scorer such as Azure AI Content Safety bills under its own terms. Run a pilot on one target with a fixed set of attacks and scorers, record the calls, then project from that data.
How long does a PyRIT cost review take?
The length depends on scope, so the answer comes from the written scope rather than a fixed number. A review that covers one target and a single scorer is shorter than one that covers several application targets, custom endpoints, memory choices and a reporting workflow. DeployOpen engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the timeline in the proposal, and ask what would change it, such as access to test environments or a late decision on model providers.
What does a PyRIT engagement need from our team?
Expect to provide a named technical contact, access to the target systems and test accounts, and a decision on which model providers and scorers you are allowed to use. You will also need someone who owns the findings, because red team results need an internal reviewer who can decide what is a real risk and who fixes it. Confirm with your security and legal teams where prompts and harmful outputs may be stored, since PyRIT memory keeps them. Agree these inputs in writing so that delays are visible early.
Can our own team run PyRIT without outside help?
Yes, in most organizations that have a named owner and people who write Python. PyRIT installs with pip, the PyPI package supports Python 3.10 up to but not including 3.15, and the documentation recommends Python 3.13. The harder part is not installation but designing attacks, choosing scorers, keeping custom targets working after each release and interpreting results consistently. Assess whether your team has those skills, and budget time for the first release cycle, when mistakes in configuration are most common.
What happens after a PyRIT engagement is handed over?
Handover should leave your team with working scenarios, documented configuration, the credential and memory setup, and a runbook for each target. After that, the recurring work is keeping PyRIT current, retesting custom targets, converters and scorers after each release, and supporting ongoing red teaming. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so you can keep that work with a partner or move it in-house. Ask the handover plan to name which artifacts are delivered and who receives them.
How DeployOpen works on this
DeployOpen works through PyRIT cost of ownership as a written, fixed-scope engagement inside your own infrastructure. We map the cost components your team will carry, from model calls and result storage to the engineering and reviewer time behind each run, and document them so you can compare options against your own environment.
How we scope
- The written scope lists which PyRIT targets, attack strategies and scorers the cost model covers.
- We identify which model API calls for attacks and scoring are billed to your accounts and at what volume.
- The scope names the memory backend, SQLite or Azure SQL, and the people who will review findings.
How we build
- We build a cost model in a spreadsheet tied to your chosen targets, scorers and run frequency, with assumptions stated.
- We test representative runs in a non-production environment and record model calls, storage growth and engineering time.
- We document which cost drivers change after each PyRIT release, such as the move from the archived Azure/PyRIT repository to microsoft/PyRIT.
How we hand over
- You receive the cost model, its assumptions, and the measured run data used to build it.
- We provide a runbook covering configuration in ~/.pyrit/.env and ~/.pyrit/.pyrit_conf, and how to rerun the cost estimate.
- Handover includes a review session where your team walks through the model and confirms the owners of each recurring cost.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering cost model updates after PyRIT releases.
- Retainer work can refresh measured run data when you add targets, scorers or attack strategies.
- Confirm with DeployOpen during quoting exactly which cost reviews and update cycles a retainer includes.
