Engineering Analytics Security Architecture: How minware Protects Source Code, AI Tool Data, and Engineering IP

TL;DR: minware computes engineering analytics without storing raw source code. An on-premise ingest agent is available to run inside your network, if desired, and connects to source systems using your own credentials, so API keys never reach minware. Source code is hashed during ingest to support quality metrics, and integrations use read-only API scopes. Whether AI coding tool data, like prompts and usage detail, reaches minware depends on how you configure your own OpenTelemetry pipeline. minware is SOC 2 Type 2 compliant, with a report covering the security criterion for the twelve-month period from October to September of the prior year. Enterprise plans include custom data residency options.

Security reviews for engineering analytics tools often come down to a single question: why does a reporting platform need access to our source code? The answer is that minware processes code to compute hashes during ingest, then discards the original. Proprietary codebase content does not persist in minware's systems, and the rest of this document explains the architecture behind that answer, including the boundaries of what minware protects.

Measuring engineering performance requires data from version control, project management, CI/CD, and AI coding tools. The sections below walk through how that data is ingested, normalized, and analyzed under four security controls, plus how AI tool data specifically is handled, with explicit notes on what the platform cannot do. Each section below can stand on its own if you need to forward just one control to a reviewer.

How minware's security architecture works: the four-pillar trust model

minware's security architecture combines four controls that together protect engineering intellectual property (IP) while still delivering the metrics your leadership team needs. Each control answers a different question a security reviewer will ask.

• Read-only API scopes: integrations authenticate with read-only permissions, limiting the ability to modify code, tickets, or pipeline configurations.

• Source code hashing: code is hashed during ingest to support metrics computation, and the original is not stored.

• SOC 2 Type 2 compliance: a report covering the security criterion verifies controls such as schema isolation and credential vaulting.

• On-premise ingest agent (optional): by default, minware connects through standard cloud integrations. Organizations that need credentials to stay entirely off minware's cloud can run an agent inside their own environment instead.

Restricting access to read-only scopes

Every integration minware offers authenticates with read-only permissions. That constraint limits the blast radius of a compromised token to data the integration can already see, with no ability to modify code, tickets, or pipeline settings. The exact scopes for each system are listed in the read-only tokens section below.

Hashing code data to avoid storing source

Source code is hashed during ingest rather than stored, on every connection type. The hashes are enough to compute code churn and similar quality metrics, while the original text never persists anywhere in minware's systems.

Verifying security controls via SOC 2 Type 2 compliance

An independent auditor verified minware's security controls over a twelve-month period, from October to September of the prior year, against the security criterion. The audit covers controls like per-customer schema isolation and encrypted credential vaulting. Enterprise plans add further isolation options on top of that compliance: single-tenant hosting and custom data residency, for organizations whose compliance requirements go beyond the standard multi-tenant, U.S.-hosted setup.

Protecting IP with an optional on-premise agent

By default, minware connects through standard cloud integrations. The on-premise agent is an additional, optional layer for organizations whose security policy requires that API keys and direct system access never leave their own environment. When enabled, the agent runs inside your network and authenticates to source systems with credentials you issue locally. Nothing about that authentication crosses to minware's cloud: the platform receives only the prepared data files the agent uploads. For organizations whose security policy forbids sharing API keys with vendors, this removes the largest objection in the review.

How the on-premise ingest agent protects your environment

The on-premise ingest agent is the pillar security teams ask about when they need additional measures, since most teams do not need it. It still deserves the deepest explanation here.

The recurring cost teams underestimate most is answering "how exactly is this calculated" every time a new stakeholder asks. With minware that is a support conversation, not an open-ended obligation for whoever built an internal pipeline.

Authenticating via the agent

The agent is a software component you deploy inside your network, on infrastructure you control. It authenticates to your version control, project management, and CI/CD systems using credentials you issue, over connections that stay within your perimeter until the prepared data files are uploaded. Because authentication happens locally, minware's cloud never sees the keys.

Locating your access tokens

With the agent, your API keys remain in your own infrastructure, and minware never receives them. The agent uses each key only to call the source system's API from inside your network. For standard cloud connections, tokens are stored in minware's systems, which is the tradeoff the agent exists to eliminate.

Verifying minimal data file exports

The agent writes standardized data files to a shared storage bucket before anything syncs to minware. Your security team can open those files to confirm what leaves your environment before it syncs to minware. The agent collects data similar to a standard connection, so the control you gain is access isolation plus the ability to inspect and limit what leaves, not pre-hashed content.

Choosing on-premise vs. standard connection

Choose the standard connection when your policy allows vendor-held tokens. Choose the agent (available on the Enterprise plan) when credentials must stay inside your environment. Both paths apply the same read-only scopes and source code hashing. Both collect the same data. The decision turns entirely on where your credentials need to live.

How read-only tokens prevent unauthorized environment access

Token design determines blast radius. Every minware integration, whether connected through the agent or through minware's cloud, authenticates with the minimum read-only permissions required to compute metrics.

Defining read-only integration limits

For GitHub, minware connects through an installed marketplace application scoped to read-only access to repository and project data. For other sources, integrations authenticate with a read-only access token. The exact scopes for each source are confirmed in minware's account configuration documentation.

Defining platform operational limits

Read-only scopes mean minware's integrations are designed not to merge pull requests, change ticket statuses, modify CI/CD configurations, or push commits. LinearB's GitHub and GitLab integrations both require a write-scoped permission to configure webhooks for real-time syncing, falling back to delayed, two-hour polling if write access is not granted, at the time of this writing. Its workflow-automation features (auto-approve, auto-merge) require write access to modify pull requests. minware does not offer workflow automation features, so minware's integrations are designed to use read access only.

Securing individual tokens

For standard cloud connections, integration tokens are encrypted at rest and held in a dedicated secrets vault. Access to the vault is restricted internally. Per-customer schema isolation in the data warehouse keeps one organization's data separated from another's.

How source code hashing protects your code without storing it

Quality metrics like code churn involve comparing file contents across commits, which normally means storing the code itself. minware avoids that tradeoff by hashing source code during ingest: hashing converts file contents into digests that support metric computation. The digests enable detection of code changes, and the original text is not stored.

Protecting IP via irreversible hashing

Hashing happens during ingest on every connection type, as described in minware's security requirements overview, so it is a platform control rather than an agent-only feature. The agent uploads the same data a standard connection would send to a shared storage location your security team can inspect before it syncs to minware. Hashing then happens during minware's ingest process, on every connection type, so source code is never stored regardless of which connection method you use. Hashing supports your proprietary code protection while still enabling churn detection and quality metrics. The original source code is not stored in minware's systems.

How AI tool data is handled during ingest

Source code hashing and read-only scopes cover version control, tickets, and pipelines. AI coding tool data, prompt text and tool-use detail collected through OpenTelemetry, works differently because it is configured on your side, not minware's. Whether that granular detail reaches minware or gets redacted first is a setting in your own OpenTelemetry pipeline.

minware ingests whatever arrives and works either way. Full detail produces more granular reporting on token spend and usage patterns. Redacted data still supports the delivery correlation your AI ROI reporting depends on. Redaction is a configuration choice available to organizations that want to limit what leaves their own telemetry setup. You can begin reporting on delivery correlation immediately, with or without that configuration in place.

How the four-pillar architecture protects your engineering IP

Engineering analytics does not require storing source code, credentials, or proprietary text. Each of the four controls, read-only scopes, source code hashing, SOC 2 Type 2 compliance, and an optional on-premise agent, answers a distinct question a security reviewer will ask. Read-only scopes limit blast radius. Source code hashing powers quality metrics without persisting the original. SOC 2 Type 2 verifies the controls behind the scenes. The optional on-premise agent keeps API keys and direct system access inside your environment for organizations that need it. You can hand this document directly to your security team.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source.

FAQs

Does minware store my source code?

No. Source code is hashed during ingest using a one-way cryptographic function. The hash is enough to compute code churn and similar quality metrics. The original text is never stored in minware's systems, regardless of whether you use the on-premise agent or a standard cloud connection.

What does the SOC 2 Type 2 compliance report cover?

The report covers the security criterion only, for the twelve-month period from October to September of the prior year. It does not cover the other AICPA Trust Services Criteria. The report documents minware's own controls, such as per-customer schema isolation and encrypted credential vaulting. It does not cover controls on the customer side.

Do I need the on-premise agent to keep my data secure?

Not necessarily. The agent is an Enterprise plan feature for organizations whose security policy requires that API keys and direct system access never leave their own environment. Standard cloud connections store tokens in minware's encrypted vault and are the faster setup path. Both connection types apply source code hashing and read-only scopes identically.

Can minware modify my repositories, tickets, or CI/CD pipelines?

No. Every integration authenticates with read-only permissions. minware does not offer workflow automation features, so no integration ever requires write access. A compromised token would be limited to reading the data the integration is already scoped to see.

Key terms glossary

Code churn: The number of code lines that are deleted within 14 days of being merged into a main branch. The hashes generated during ingest support this calculation; no source code text is stored to produce it.

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. The agent uploads standardized data files to a shared bucket, which your security team can inspect.

Read-only API scopes: Integration permissions restricted to reading data only. minware uses these for every connection to version control, project management, and CI/CD systems, preventing any modification to code, tickets, or pipeline configurations even in the event of a compromised token.

Source code hashing: A platform-level ingest step that converts file contents into fixed-length cryptographic digests during ingest. The digests enable churn and quality metrics. The process is one-way and applies to all connection types, not only agent connections.

SOC 2 Type 2: An independent audit standard covering security, availability, and related criteria over a defined period. minware is SOC 2 Type 2 compliant, with a report covering the security criterion only, for the twelve-month period from October to September of the prior year.

Single-tenant hosting: A deployment configuration available on Enterprise plans where a customer's data and compute are isolated to dedicated infrastructure rather than shared with other tenants.

Custom data residency: An Enterprise plan option that allows the customer to specify the geographic region where their data is stored, to satisfy regulatory or organizational data-location requirements.