AI Spend Management Security and Compliance Guide

TL;DR: A security reviewer evaluating a tool that ingests AI spend data needs five answers. minware is SOC 2 Type 2 compliant for the security criterion only, audited for the most recent year ending in September. Professional runs on U.S. multi-tenant hosting, with custom data residency and single-tenant hosting on Enterprise. Integrations use read-only tokens, with secrets held in an encrypted vault. Enterprise teams that can't share GitHub or Jira credentials can run the optional on-premise ingest agent, which uses their own credentials so those keys never reach minware. minware can sign a Business Associate Agreement (BAA) for enterprise customers handling protected health information (PHI).

Security reviewers ask predictable questions. Approval tends to stall when the vendor's answers are vague or its compliance evidence is scoped too broadly. It also stalls when the architecture leaves open where credentials and source data live.

This guide walks through each control in the order a reviewer asks for it: SOC 2 scope, data residency, on-premise ingest architecture, credential handling, data visibility, and BAA availability. It names the specific evidence to request and the honest scope boundaries to state, so you arrive at the review with answers already prepared.

Understanding why security reviewers block these tools

Software development analytics platforms that ingest AI token spend alongside version control, project management, CI/CD, and AI coding tool data face close scrutiny because of what they connect. Granting a single vendor access to source code metadata, ticket history, deployment records, and financial token cost data creates a concentration of access that triggers the review.

Three gaps can block approval. The vendor's SOC 2 scope may be unclear or overstated, which makes the report unreliable as evidence. There may be no way to keep source-system credentials inside the network, so the reviewer has to grant the vendor direct API access. The vendor may struggle to explain how API keys are stored, scoped, or revoked. Each of these is answerable, but only if the vendor's architecture and compliance documentation are specific enough to hold up.

Closing the specificity gap

The gap between a vendor's security page and a reviewer's checklist is usually specificity. A security page that says "we take security seriously" does not answer a single review question. Request the SOC 2 report with its scope boundary stated, plus architecture and credential handling details. minware shares architecture details on request.

Reading the SOC 2 Type 2 report scope

SOC 2 Type 2 is an attestation report in which a licensed CPA firm examines the vendor's controls against the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria and issues a formal opinion. As Vanta's compliance guidance explains, SOC 2 is an attestation from a licensed CPA, so the report itself is the evidence to review, starting with its scope boundary. Many enterprise customers now require SOC 2 as a baseline. A Type 2 report tests whether controls operated effectively over a period, where a Type 1 report evaluates design at a point in time.

minware is SOC 2 Type 2 compliant, audited for the most recent year ending in September, covering the security criterion only. The SOC 2 Type 2 report is openly available. That scope boundary matters: the audit covered the security criterion, while availability, confidentiality, processing integrity, and privacy fall outside its scope.

A vendor that claims SOC 2 compliance without naming which criteria were audited is leaving the scope question open, and a reviewer will ask. Stating the boundary upfront is more credible than implying broader coverage.

Mapping what the audit covered

The report's system description commits minware to least-privilege access. It also commits minware to encrypting client data at rest and in transit. AWS and Snowflake are carved out as subservice organizations, so the examination did not test their controls, including Snowflake's segregation of minware's environment from other Snowflake customers. Read-only integration tokens, per-customer schemas, the encrypted secrets vault, and source code hashing are described in minware's security documentation. A reviewer who needs the carved-out controls covered can download AWS's compliance reports and request Snowflake's attestation reports.

minware is not ISO 27001 certified. Some reviewers will flag that gap, particularly those at organizations with international compliance requirements. The existing evidence is the SOC 2 Type 2 report covering the security criterion. If your reviewer requires ISO 27001 specifically, raise that before the trial begins.

Managing data residency and storage

Expect questions about where your engineering data lives and who can access it before approval.

Locating and choosing where data is hosted

minware loads data from your connected tools into a Snowflake data warehouse, including all available fields and their history where the source provides it, with per-customer schema isolation. Each customer's data sits in its own schema, which lets minware run authorization checks at the schema level. The Professional plan uses multi-tenant U.S. hosting. Enterprise customers can configure custom data residency and dedicated single-tenant hosting.

Exporting data for compliance audits

If your organization applies retention or audit rules to token spend records, minware supports CSV export from every report and Model Context Protocol (MCP) access for agent-driven queries, so you can pull data into whatever audit or compliance tooling you already use. Enterprise customers can also query the data warehouse directly via SQL or Open Database Connectivity (ODBC).

Keeping credentials in your network with the on-premise agent

The on-premise ingest agent is an optional deployment on the Enterprise plan for teams that can't grant minware direct API keys or access to source systems. The primary benefit is access control: API keys and direct source access stay in your environment. It runs inside your network, connects to source systems using your own credentials, and uploads data files to a shared storage bucket that minware reads from. By default, the data minware stores is the same as with a standard connection.

The agent keeps unused API fields out of minware's reach, and depending on how a field is used, sensitive fields may be omitted or hashed in the agent.

Understanding the agent architecture

The agent handles three steps: extract, process, upload. It connects to your GitHub or Jira APIs, whether cloud or self-hosted, retrieves data, processes it locally, and uploads the result to a shared storage bucket. minware then reads from that bucket and proceeds with loading. The on-premise agent documentation describes the full setup. The key architectural point is that minware never has direct access to your source systems.

To review data before minware sees it, your team can point the agent at a private staging bucket first and inspect the files there. The minware-provided output bucket requires encryption in transit (TLS 1.2 minimum) and at rest (AES-256-GCM), with a key unique to your organization. Only you and minware can access it.

Securing ingest agent permissions

Because the agent uses your own credentials, you define the permission scope and can hold it to the principle of least privilege.

For GitHub, the agent documentation lists read-only permissions for a fine-grained personal access token. A classic token needs the repo scope, which GitHub grants with write access, so use a fine-grained token to keep the agent read-only. The tradeoff is that you operate the agent, so you own that credential surface. Your team manages the agent's uptime, its network access, and its credential rotation. That is a real operational cost, and it is worth naming in the review so there are no surprises after approval.

Comparing standard and on-premise connections

The decision between a standard connection and the on-premise agent comes down to your organization's tolerance for external API access. A standard connection requires granting minware read-only API tokens. The on-premise agent requires your team to deploy and operate the agent inside your network. By default, both produce the same stored data. The difference is who holds the credentials and who can inspect what leaves. The on-premise agent model keeps GitHub and Jira credentials out of the vault, because those keys never leave your environment. The agent authenticates to your source systems locally and uploads only the output files. This is the stronger control for organizations that cannot grant external API access under any circumstances.

Safeguarding API keys on a standard connection

When you use a standard connection rather than the on-premise agent, minware handles your API keys through three controls: read-only token scoping, encrypted vault storage, and revocation from your source system. Read-only scoping and revocation are visible from your side in the source system. Vault storage is operated by minware, so the evidence for it is minware's security documentation and the SOC 2 report's system description.

Storing and scoping integration tokens

Every integration token is read-only. minware holds all customer API keys and secrets in an encrypted vault that the web application cannot read once they're written. Only ingest tasks can read them. The token lifecycle follows a standard pattern: scoped at creation to read-only access, stored in the vault, and revocable at any time from your source system. You revoke a standard connection by suspending or uninstalling the marketplace app in GitHub or Jira, or by deleting the access token in whichever system issued it for other sources. Because each customer's data sits in its own schema, minware can delete all data with a single query.

Controlling what AI tool telemetry sends

AI coding tool usage and token spend reach minware through vendor APIs and OpenTelemetry integrations. Whether prompt text and tool-use detail are included is set in your own OpenTelemetry configuration, not in minware. minware ingests whatever arrives. Full detail supports more granular token spend reporting, while redacted data still supports the delivery correlation behind AI ROI reporting.

Controlling who can see ingested data

Concentrated access in a single vendor raises a parallel question: once data is ingested, who can see it. Role-based access control (RBAC) and SSO/SAML answer that, so reviewers check them early. minware offers four configurable visibility tiers:

• Fully open

• Individual data visible to the immediate team only, with open team-level access

• Individual data visible to managers and executives only, with full team-level access

• Full tenant segmentation, for organizations that can't share any data across teams

Your admins choose the tier as a configuration setting, with roles for individuals, managers, and executives. Enterprise plans include SSO/SAML for centralized identity management.

Managing BAAs for HIPAA compliance

A Business Associate Agreement (BAA) is required under the Health Insurance Portability and Accountability Act (HIPAA) when a covered entity shares protected health information (PHI) with a third-party vendor that creates, receives, maintains, or transmits that data on their behalf. The HHS guidance on business associates defines the applicability criteria.

The trigger is whether PHI flows through the tool. If your engineering data includes PHI (for example, ticket descriptions referencing patient records or commit messages containing health data), a BAA is required before the vendor can process that data.

minware can sign a BAA for enterprise customers, so HIPAA-regulated teams should evaluate the Enterprise plan, which also adds SSO/SAML, custom data residency, and single-tenant hosting. Bring the SOC 2 report to the same conversation as the BAA.

Using the IT approval checklist

This checklist is the artifact you hand to your security reviewer. It organizes the evaluation by question, evidence to request, and minware's specific answer.

The seven questions in the IT approval checklist cover the five core answers plus ISO 27001 status and data visibility. If your reviewer asks something not on this list, the answer should still follow the same pattern: name the control, state the scope boundary, and provide the evidence document. Vague answers are what stall reviews.

Request these before the review meeting:

• The SOC 2 Type 2 report

• Architecture and credential handling details

• The security documentation

• A BAA template if applicable

• The RBAC configuration options

Question	Evidence to request	minware's answer
What does SOC 2 cover?	SOC 2 Type 2 report with scope boundary	Security criterion only, most recent year ending in September, report openly available. AWS and Snowflake carved out as subservice organizations
Where does data reside?	Data residency documentation	U.S. multi-tenant (Professional), custom residency and single-tenant (Enterprise)
How are API keys handled?	Credential handling model	Read-only tokens, encrypted vault
Is there an on-premise option?	Agent architecture documentation	Optional on-premise ingest agent (Enterprise), customer credentials, optional staging-bucket review
Is a BAA available?	BAA template or commitment	Yes, for enterprise customers handling PHI
Is the vendor ISO 27001 certified?	ISO 27001 certificate	No. SOC 2 Type 2 security criterion is the existing evidence
Who can see what data?	RBAC and access control matrix	Four visibility tiers, SSO/SAML on Enterprise

Preparing for your next security review

Security reviews for software development analytics platforms follow a predictable pattern. The reviewer wants to know what the SOC 2 report covers, where data lives, how credentials are handled, whether an on-premise option exists, and whether a BAA is available. Having the evidence documents ready gives the reviewer an answer for each question on their list. Your team configures visibility tiers, SSO, excluded repositories, OpenTelemetry redaction, credential scope, and on-premise deployment. minware operates schema isolation, encrypted vaulting, and source code hashing. The SOC 2 report and the IT approval checklist are the two artifacts to bring, with the on-premise agent as the option for teams that cannot grant external API access.

Start a 14-day free trial, no credit card required, and connect your first data source. You can explore the platform and review the security documentation before involving your team.

FAQs

Is minware SOC 2 Type 2 compliant?

minware is SOC 2 Type 2 compliant, audited for the security criterion only over the most recent year ending in September. SOC 2 Type 2 is an attestation report from a licensed CPA firm, and the SOC 2 Type 2 report is openly available.

Can we use the on-premise agent to keep credentials internal?

Yes, on the Enterprise plan. The on-premise ingest agent runs inside your environment, connecting to GitHub or Jira with your own credentials, so API keys and direct source access never reach minware. To review data before minware sees it, point the agent at a private staging bucket first and inspect the files there.

Is a BAA available for HIPAA-regulated organizations?

Yes, minware can sign a BAA for enterprise customers. The trigger is whether PHI flows through the tool, so confirm applicability with your compliance team before requesting one.

What data from version control and ticketing systems is collected?

minware loads all available fields from your version control, project management, CI/CD, and AI coding tool integrations, plus the full history of each field where the source provides it. Source code is hashed during ingest and never stored. Some non-code files, such as agent instruction markdown or package dependency files, may be stored to support file-content insights. Teams using the optional on-premise agent can review the output in a private staging bucket before sharing it with minware.

Does minware receive prompt text from AI coding tools?

It depends on your OpenTelemetry configuration, which you control. minware ingests whatever your setup sends. Full prompt and tool-use detail supports more granular reporting, while redacted data still supports the delivery correlation behind AI ROI reporting.

Key terms glossary

SOC 2 Type 2: An attestation report from a licensed CPA firm that audits a service organization's controls against the AICPA's Trust Services Criteria over a defined period.

Trust Services Criteria: The five categories the AICPA uses to evaluate controls: security, availability, processing integrity, confidentiality, and privacy.

BAA (Business Associate Agreement): A contract required under HIPAA when a third-party vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity.

PHI (protected health information): Individually identifiable health information regulated under HIPAA. Its presence in engineering data triggers BAA requirements.

On-premise ingest agent: An optional deployment agent that connects to a customer's internal systems using their own credentials, so API keys and system access never reach minware.

Data residency: The geographic location where data is stored and processed. Relevant for organizations with jurisdictional requirements.

RBAC (role-based access control): A permissions model that restricts data visibility based on user roles, such as individual, manager, or executive.

SSO/SAML: Single sign-on using Security Assertion Markup Language, allowing centralized identity management and authentication.

Read-only token: An API credential scoped to read access only, preventing the vendor from writing to or modifying source systems.

Schema isolation: A database architecture where each customer's data sits in its own schema, letting minware run authorization checks at the schema level.

Single-tenant hosting: A deployment where a customer's data and processing environment run on infrastructure dedicated to that customer. Available on the Enterprise plan.