Agentic SOC via marketplace: a buying and contract guide

One more vendor in the registry. A contract with its own terms, a dollar invoice that sits outside the cloud bill, and a renewal calendar that finance never crosses with the cloud budget. The direct route to managed detection and response works, and it charges in paperwork what it should charge in decision.

The approved proposal, though, can enter through the cloud account. An agentic SOC (Security Operations Center, the team and system that detect and respond to security incidents, operated by AI agents with human validation) changes counter, not function. The question stops being how much it costs and becomes who answers.

This piece is written from the buyer's side. The findings that Security Hub already aggregates in the account keep leaving it through a cross-account authorization that the buyer grants and has to review at every renewal. The invoice consolidates. The accountability does not.

What buying an agentic SOC through the marketplace solves

Buying an agentic SOC through AWS Marketplace uses the cloud agreement already in force: the purchase enters as a line on the consolidated bill, with price and term set in a private offer. The Aurora Agentic SOC announcement, published on the AWS Marketplace blog on October 16, 2026, attributes to that route less contracting overhead, simpler procurement and consolidated billing.

The subscription does not define who answers for the operation, and that is where the invoice stops solving anything.

Those are the announcement's attributions, not measurements.

For anyone already buying security as a service, the novelty is not in the service. It is in where the service is bought.

The table uses five criteria and applies the same logic as direct purchase or software marketplace to a continuous service.

The announcement cites the ISC2 2025 AI Pulse Survey, which estimates that 30% of security teams have already integrated AI tools into operations.

The invoice consolidates, the access does not

The pipeline that feeds the SOC runs in the buyer's AWS account. Security Hub CSPM aggregates the findings in ASFF, EventBridge fires the event, Firehose carries it to S3, Lambda enriches it, and the SOC reads the bucket through cross-account IAM authorization. The consolidated bill does not reduce that access.

GuardDuty, Inspector, Macie, Config and third-party tools deliver findings to Security Hub CSPM, which normalizes them in ASFF (AWS Security Finding Format). EventBridge fires on every finding, with no polling.

Firehose carries the event to S3 with buffering and batching. Lambda processes, enriches and routes to a destination bucket, and the SOC reads that bucket through cross-account IAM.

The vendor's CloudFormation templates deploy that pipeline into the buyer's account. The system that produces the data lives on the buyer's side.

The agents in the Swarm of Experts framework run triage, investigation and response in the SOC, with human analysts validating and escalating. The integration described reads the destination bucket, and what that read reaches is in the IAM role and in the contract, not in the announcement.

The vendor states that it monitors more than 10,000 customers, processes more than 10 trillion security events per week and holds more than 14 years of curated data.

The AWS Shared Responsibility Model organizes the rest: AWS answers for the security of the infrastructure, and the buyer remains responsible for what runs in its account, including the resources the vendor's stack creates. The cross-account trust is granted, reviewed and revoked in the buyer's account. The vendor assumes the role and operates the SOC on its own side.

What is left to the buyer is the operational part that does not appear in the proposal: Firehose quotas, bucket lifecycle, consumption cost and the reading of findings by a third party. That is contract, not architecture.

What it costs: subscription and consumption are two bills

The purchase creates two cost lines. The subscription has a price and a term negotiated with the vendor and appears on the consolidated AWS bill. The pipeline consumes AWS services paid per use, billed directly to the buyer. Approving only the first line leaves the second one without an owner.

The second line negotiates with nobody. Every finding becomes an event in Firehose, an object in S3 and a Lambda invocation. The buyer pays AWS for the resources the stack creates and for processing the findings, separately from the subscription.

Consolidated billing on AWS puts the two on the same invoice. Only one of them was negotiated, and the difference crosses the quarter without explanation.

Anyone using the mechanics of buying software through the cloud marketplace against a spend commitment has to check in the agreement itself whether the subscription counts toward the commitment and how consumption of AWS services enters the quarter's tally.

The tax treatment of the remittance is not the subject of this text.

The budget question is not the subscription price. It is who signs the variable line when the volume of findings doubles in an incident week.

Term, renewal, and the difference between switching off and cancelling

Term, renewal and cancellation follow the terms of the agreement negotiated with the vendor, and the announcement says so explicitly. Technical removal is another matter: deleting the CloudFormation stacks stops the flow of findings and does not cancel the subscription.

There are two calendars, and they almost never coincide. The contract's calendar has a start, a term, a cancellation window and a renewal date. The account's calendar has installed stacks and destinations pointing at a bucket.

Deleting the stacks stops the flow of findings, and the subscription stays active. The invoice arrives anyway, because the subscription lives in the agreement, not in the stack. Whoever ends the operation without ending the contract pays for a service that no longer receives data.

The opposite also happens, and costs more: the contract ends, the pipeline stays installed, capturing findings, spending Firehose and filling S3 with a destination nobody reads. Neither side uninstalls out of courtesy.

Renewal follows the agreement, and what it says has to be read in the clause, not inferred from the invoice.

Two questions settle this before the subscription. Who notices the renewal, and who uninstalls?

Approval and budget: who signs, who owns the line, who notices the renewal

Consolidating the charge changes the approval path. The purchase starts competing with the cloud budget, and the owner of the line is no longer necessarily the person who operates the service. Three fields have to be defined before the subscription: owner, budget line and renewal alert.

When the subscription enters the cloud invoice, it stops being a security purchase and becomes a cloud line. Whoever approves the cloud budget is rarely whoever approves a security tool, and the amount competes with instances and spend commitments.

The private offer defines price, term and conditions. Whoever negotiates is usually procurement. Whoever operates is the security team. Whoever pays the variable line is usually nobody, until the first incident.

Separating the three functions is a design decision. Service owner, line owner and alert owner can be the same person, as long as it is written down.

The line has to circulate. Embedding procurement in the flow with marketplace APIs takes the charge to procurement and to the ERP, where renewal stops depending on memory.

What to check before signing

Nine checks need an answer before the subscription. The first three deal with what the agents can do, the credential used and the scope of the cross-account read. The rest cover retention, cost on the AWS side, price unit, renewal, data and the split between what AWS covers and what is left to the buyer.

1. Agent scope and the human validation point. Agents run triage, investigation and response, and human analysts validate and escalate.
2. Which credential the vendor uses. The read is through cross-account IAM, granted in the buyer's account, and revocation needs an owner and a deadline.
3. What the cross-account read reaches. Which bucket, which prefix, and whether the scope grows.

The first three define what the vendor can see, and legal reads them with the security team.

1. Retention and bucket lifecycle. Who defines expiration, who pays for storage and where the history goes.
2. Prerequisites and cost on the AWS side. Security Hub and GuardDuty have to be enabled, besides an active subscription, and they generate consumption.
3. Unit of measure of the price in the private offer. Per user, per volume or per asset, and what makes the number go up.

The middle block sits outside the commercial proposal, and it is where the cost shows up later.

1. Renewal, cancellation and what survives the end. Renewal follows the agreement, and what survives is what was not uninstalled.
2. Data handling, subprocessors and residency. The pipeline runs in the buyer's account and the SOC reads the destination bucket, so the data crosses the boundary between the two accounts at every processed finding.
3. What AWS covers and what is left to the buyer. The security operation is what the buyer signs back.

None of the nine is new to anyone who has already bought security. All of them change with a purchase through the marketplace.

When the marketplace is the wrong route

The marketplace route is the wrong one when the team cannot operate the pipeline inside its own account, when the third-party read does not pass the data policy, or when the purchase has to go out in local currency with a local invoice document. In those cases, consolidation does not pay for itself.

The first is operational. Without an owner for quotas, bucket lifecycle and IAM review, the company inherits the work.

The second is about data. A policy that does not allow continuous third-party reading does not change because the invoice became simpler.

The third is about contracting. When the purchase has to go out in reais, with a local invoice document and a defined contracting point, the route changes. Nexforce Marketplace contracts international software and AI solutions with pricing in reais, a Brazilian invoice and centralized procurement, with budget and renewal alerts.

Billing consolidation solves the invoice, not the accountability. Nexforce Marketplace changes the currency, the invoice document and the contracting point. It does not change who answers for the security operation.

https://nexforce.ai/marketplace

The cloud marketplace route pays off when the team operates the pipeline in its own account and the third-party read passes the data policy.

Frequently asked questions

What changes when buying an agentic SOC through the marketplace?

The subscription uses the AWS account the company already has, with price and term set in a private offer and the charge on the consolidated bill. What does not change is the operation. The pipeline keeps running in the buyer's account, with the same responsibility over the operation.

What happens to the pipeline if the contract ends?

The managed SOC stays installed. The CloudFormation stacks remain in the account, capturing findings and consuming Firehose, S3 and Lambda. Deleting those stacks stops the flow of findings and does not cancel the subscription. Who uninstalls, and by when, is defined in the contract, including on the last day of its term.

Who pays for the AWS consumption the pipeline generates?

The buyer. The subscription covers the vendor's service, and the pipeline consumes AWS services paid per use, billed directly to the account. Security Hub and GuardDuty have to be enabled, and Firehose, S3 and Lambda grow with the volume of findings processed in incident weeks.

What should be checked in cross-account access before signing?

Which bucket the vendor reads, with which prefix, through which account and through which credential. Also check how that authorization is revoked and whether the scope can grow without new approval. When the contract ends, someone has to define who takes the history and who deletes what is left.

When does buying SOC through the marketplace pay off?

It pays off when the team can operate the pipeline inside its own account and the third-party read passes the data policy. When the purchase has to go out in local currency, with a local invoice document, the cloud marketplace stops being the simplest route.

References

Announcement "Resolve security signals faster with Arctic Wolf's Aurora Agentic SOC", AWS Marketplace blog, October 16, 2026. https://aws.amazon.com/blogs/awsmarketplace/resolve-security-signals-faster-with-arctic-wolfs-aurora-agentic-soc/ Accessed October 23, 2026.

ISC2 2025 AI Pulse Survey, cited in the announcement above. Accessed October 23, 2026.

AWS, Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/ Accessed October 23, 2026.

The next step

The next task fits on one page: take the nine checks to the table where legal reads with the security team, write the three names (service owner, budget line owner and renewal alert owner) and ask for the private offer with its price unit and the revocation path for cross-account access written into it. Whatever stays outside those three lines shows up in the following quarter, in the first incident week when the volume of findings doubles.

After that the decision is simple. When the purchase has to go out in reais, with a Brazilian invoice document and a defined contracting point, Nexforce Marketplace contracts international software and AI solutions with pricing in reais, a Brazilian invoice and centralized procurement, with budget and renewal alerts. It changes the currency, the invoice document and the contracting point. It does not change who answers for the security operation, and that part stays in the buyer's account, with the pipeline and the cross-account access under the IAM the company grants and reviews.