How the loop works

Your agent prepares grounded answers at the start. We turn the reviewed intake into a package that the same agent can continue working with after delivery.

1. Inspect

The agent reads sources it can already access, including repository configuration, infrastructure-as-code, CI, identity settings, and public company policies.

2. Review

It emits a schema-valid intake.json and a source report. You review every answer before the form records it as buyer-attested.

3. Continue

The delivered zip includes AGENTS.md and manifest.json, so your agent can fill remaining markers, run evidence routines, and prepare updates without inventing facts or signing for a human.

Paste this into your agent

Run the agent inside the company repo or workspace where it can inspect the relevant files. Grant read-only infrastructure access only when you already use that access safely.

# Prepare a soc2.zip intake.json

You are preparing a draft intake for a SOC 2 readiness package. Your output is
reviewed by a human before submission. Do not guess, invent evidence, or expose
secrets.

## Contract

1. Read https://soc2auditors.org/soc2zip/intake-schema.json.
2. Create intake.json that validates against that JSON Schema.
3. Omit any field you cannot support from a source you inspected.
4. Do not include credentials, tokens, personal data, production records, or
   copied secret values.
5. Do not claim a control passed merely because tooling or configuration exists.

## Inspect

- Repository docs, package manifests, deployment config, CI workflows, and
  infrastructure-as-code.
- Cloud account configuration through read-only commands, when access is
  already available.
- Identity-provider and endpoint-management configuration, when access is
  already available.
- The company's public privacy policy, trust or security page, and subprocessor
  disclosures.
- Existing policy, evidence, audit, and vendor-management files in the repo.

## Output

- Write only fields supported by the inspected sources.
- Use the schema's exact enum values and data types.
- Do not add _provenance. The intake form records provenance after buyer review.
- Put the final object in intake.json.
- Separately report each populated field with its source path or read-only
  command, plus every field you omitted and why.
- Leave human review, attestations, and submission to the buyer.

Expected file shape

Every field is optional in the draft contract. A short, sourced file is better than a complete-looking file built from assumptions.

{
  "company": "Example Labs, Inc.",
  "website": "https://example.com",
  "headcount": "11-50",
  "stack": ["AWS", "GitHub", "Postgres-managed"],
  "industry": "B2B SaaS",
  "audit_target": "Type 2"
}

Review boundary

The agent output is a draft. Open it in the intake form, verify each answer, correct anything stale or incomplete, and submit only when it reflects your company.

What the agent must not collect

Do not put credentials, access tokens, customer records, employee records, production data, or copied secret values in intake.json. The intake needs company and control-posture facts, not the sensitive data those controls protect.

Why sources still matter

A repository setting can support a fact about branch protection. It cannot prove every change followed the process for an audit period. The agent should distinguish configuration from operating evidence, report the source for each field, and omit facts it cannot defend.

Next step

Review the generated intake.

Import the agent's JSON, confirm each populated field, and answer only what your sources could not establish.

See soc2.zip View the schema

Your agent has access we never will.