AI Security Posture
This page exists so your security team can evaluate ProductHarness before anyone schedules a session — not after. The engagement does not proceed past intake without their disposition.
The Objection, First
ProductHarness asks product managers to work in a developer environment with an AI coding agent — with the org's requirements, standards, and prototype code in that agent's context. If your organization sells or operates data security products, your own tooling may classify that activity as exactly the behavior it polices.
That objection is correct as far as it goes, and this page doesn't argue around it. It explains why the framework is the governed version of behavior that is already happening ungoverned, what the actual data flows are, and what your team should verify before approving anything.
You are not being asked to accept a new risk. You are being offered observability over an existing one.
Not a Product. Not a Service. Not Even Files From Outside.
From a security standpoint, ProductHarness is a specification and a set of practices. No repository, package, or binary is ever distributed to you. Your own AI coding agent generates the harness repo from the specification — inside your source control, reviewed by your team, yours from the first commit. The specification itself is plain-text documents, reviewable in under an hour. (Public reference repositories exist for learning; they are examples, never delivered into your environment.)
There is no hosted service, no account, no third party processing your data, and nothing that phones home. Nothing is cloned from the author's infrastructure — the harness is generated by your agent, in your environment, from a specification your team can read first. There is no runtime dependency on the author or any external endpoint introduced by the framework. The author never holds your data — there is nothing to grant.
The harness bundles no model and requires no specific agent. It operates through whatever agentic coding tool your org has already approved for engineering. If no agent is approved, that approval comes first — the framework will not be the reason an unapproved tool enters the building.
The harness changes what is in context for an already-approved tool. It does not change where data goes. The agent-to-provider flow is governed by your existing vendor agreement — the same one that governs your engineers' use of the same agent on production code.
What Enters the Repo — and What Never Does
The boundary is your classification policy, not the framework's default — your policy is imported into the harness's security steering document during setup, which means the agent itself has your data classification rules in context at all times. That is more than can be said for a PM pasting into a consumer chatbot.
| In the repo, by design | Never in the repo, enforced |
|---|---|
| Steering documents — conventions, component standards, API patterns, node definitions | Credentials, tokens, keys — these live in a gitignored env file; committed config carries placeholders only |
| Requirements, acceptance criteria, discovery artifacts, decision logs | Customer data or production data in any form — prototypes run on synthetic data, full stop |
| Prototype code and the synthetic data created to exercise it | Anything exceeding the classification level your team approves for agent context |
Enforcement is layered, not aspirational: gitignore and env-file separation (structural), secret scanning in CI (automated), classification rules in agent context (behavioral), and human review gates before anything is published downstream (procedural).
Governed vs. What's Happening Now
The alternative to the harness is not "PMs don't use AI." It is PMs using AI through channels you can't see. The comparison that matters:
| Ungoverned — the status quo | Governed — the harness | |
|---|---|---|
| Where it happens | Personal chatbot accounts, browser tabs | Your source control, your approved agent |
| Visibility | Invisible until DLP catches a paste | Every input and output version-controlled; full audit trail |
| Data terms | Consumer terms; possible training use | Your negotiated enterprise agreement |
| Classification awareness | Whatever the PM remembers | Your policy, in agent context |
| Accountability | None | Commit history, PR review, named owners |
For a data security vendor specifically: agent traffic from a managed developer environment is a known, policy-enforceable surface — inspectable by your own products. The framework consolidates product-org AI use into the one channel your team can actually see.
Seven Threats, Honestly Mitigated
Each entry names the residual risk owner — because "mitigated" without an owner is marketing.
| Threat | Primary mitigations | Residual owner |
|---|---|---|
| T1 · Sensitive data entering agent context | Classification rules in agent context; synthetic-data-only prototyping; repo scoped to product artifacts; vendor retention terms (checklist below) | Data governance — same owner as engineer agent use |
| T2 · Prompt injection via repo or fetched content | Org-authored, PR-reviewed content; allowlisted internal sources only; human-in-the-loop gates on every publish, merge, and distribution; no autonomous write path to production | AppSec, scoped by the MCP allowlist |
| T3 · Exfiltration via integration (MCP) servers | Security-team allowlist; least-privilege credentials per server; credentials never committed; egress from managed workstations, visible to your network and DLP controls | Identity/secrets management — existing process, new principal |
| T4 · Secrets leaked into version control | The specification requires the generated repo to gitignore env files from its first commit and to carry placeholders only in committed config — your team verifies the generated output before first use; secret scanning in CI; private-repo blast radius | Platform engineering — identical to any repo |
| T5 · Supply chain — the specification itself | Nothing executable is distributed: the spec is plain-text documents your team reads before any agent acts on them; the harness is generated inside your environment by your own approved agent; the generated repo is reviewed by your security team before first use — it is org-authored from commit one; no binaries, no remote fetches, no contact with author infrastructure, ever | Security review of the spec and the generated repo, once, at adoption |
| T6 · PM-generated code reaching production | Prototypes are explicitly non-production; promotion passes engineering's existing branch protection, review, and CI; engineering owns implementation soundness as a stated governance rule | Engineering leadership — the same gate as all merged code |
| T7 · Model training on org data | A vendor-agreement question, consolidated under the one agreement your org has actually reviewed instead of N consumer accounts under none | Procurement / legal |
Eight Things to Verify with Your Agent Vendor
The framework names no vendors. Verify these with whichever agent your org has approved — most enterprise offerings answer all eight in writing. If engineering already uses the agent, these are already answered; the review simply confirms the product org inherits the same terms.
What is retained from agent traffic, for how long — and is zero-data-retention available and enabled?
Contractual commitment that your data is not used to train models.
Current SOC 2 Type II at minimum; ISO 27001; sector attestations as relevant.
Where data is processed; regional processing commitments if your obligations require them.
Enterprise tenant isolation; private/VPC deployment or customer-managed keys if your classification level demands it.
Org-level usage visibility, audit logs of agent activity, ability to disable features org-wide.
The vendor's position on output ownership and copyright indemnification.
Current subprocessor list and change-notification terms.
The Posture Review, Step by Step
A process with an exit — not a vibe. Your security team's decision rights are explicit: they can veto any data flow, and "no integrations in phase one" is a valid outcome. The harness degrades gracefully to repo-only operation, which preserves the core model with zero integration surface.
Your team supplies three things
The approved coding agent and its agreement status against the checklist, the integration allowlist, and your data classification policy for import into the harness's security steering document.
Threat model, against your specifics
A 60–90 minute walkthrough of the seven threats with your reviewers. Disagreements narrow scope rather than kill the engagement.
Written sign-off
Approved scope, conditions, and a named security contact — appended to the Day One plan. The engagement proceeds on those terms and no others.
Asked Directly, Answered Directly
Because your PMs are already doing it — ungoverned. The harness replaces invisible consumer-channel AI use with a channel inside your perimeter, under your enterprise agreement, visible to your own products.
Nothing, structurally — no service, no telemetry, no credentials, no data, and no repository of yours, ever. The delivery model is one-directional: a specification comes in, your agent generates the harness, and the author never has visibility into what was generated. During an engagement the author works in your environment under your access controls, like any contractor, with access yours to scope and revoke.
Yes. Distribution automation is a capability tier, not a requirement. Repo-only operation preserves the core build–validate–derive model with zero integration surface.
A named human, always. The framework's first principle is that AI drafts and people decide — every artifact that moves downstream carries a human approval in version control.
Questions this page doesn't answer go to davidj@outlook.com — they'll be answered in writing, and the good ones will be added here.