Compliance and Security Pack

General Augment is the agent backend for your app. This pack helps a customer, partner, or security reviewer understand the current security and compliance posture for an app integration that calls POST /v1/responses, stores project-scoped data, and may use memory, tools, approvals, traces, and audit logs.

This pack is customer diligence material for the GA platform. SOC 2, ISO 27001, HIPAA, BAA, DPA, retention, and SLA commitments are represented when they are included in the accepted customer agreement, audit evidence, or attestation packet.

Use this page as an assembly checklist for diligence materials that support customer security review and Enterprise contracting.

Executive summary

General Augment can assemble a strong diligence pack with product security docs, architecture summaries, redacted evidence exports, and policy artifacts. Those materials support GA customer launches, Enterprise review, and integration-readiness checks.

The pack should distinguish three things:

Category	Meaning	Examples
Current platform controls	Controls already represented in the product or hosted baseline.	Project-scoped API keys, `/v1/responses`, tenant-scoped memory, credential vaulting, auth proxy boundaries, approval gates, PII-redacted tool-call audit rows, trace IDs, usage limits, GCP managed encryption at rest.
Evidence artifacts to prepare	Screenshots, exports, logs, policies, and inventories that prove or explain the controls.	Security overview, data-flow diagram, subprocessor inventory, redacted audit-log samples, access review, incident template, DR/backup evidence, retention matrix, customer checklist.
Customer agreement or third-party attestation	Commitments backed by accepted terms or external evidence.	SOC 2 Type I or Type II, ISO 27001, penetration test attestation, signed DPA, BAA, SCCs, contractual breach notice terms, audit rights, custom residency or deletion SLAs.

Platform evidence General Augment can produce

General Augment can produce these materials for customer diligence:

Product security overview covering tenant isolation, server-side credentials, approval controls, logging, and prompt-injection boundaries.
/v1/responses data-flow diagram showing app backend, General Augment API, memory, tools, traces, usage, and audit events.
Current subprocessor and service inventory, clearly marked as “current as of” a specific date and verified against live configuration.
Privacy and data-use statement explaining what customer content is used for, including the no-training-by-default posture.
Security policy draft covering encryption, API key handling, secrets, vulnerability intake, change management, and secure development.
Access-control evidence such as a dated roster of production admins, MFA posture, least-privilege notes, and the last access review.
Redacted logging and audit examples showing response IDs, trace IDs, usage metadata, memory receipts, and tool-call audit rows without secrets or raw customer data.
Incident-response policy and timeline template for customer-impacting incidents.
Disaster-recovery and backup summary, including current Cloud SQL backup/PITR posture and restore-drill evidence when available.
Data-retention and deletion matrix that separates primary-store deletion from backup retention and operational-record retention.
Vendor-risk questionnaire response library with standard answers and evidence links.

These artifacts should be dated, owner-assigned, and regenerated after major changes to hosting, providers, data retention, support, or security-sensitive product behavior.

Customer-specific commitments

Represent these items through the accepted customer agreement, audit evidence, or attestation packet:

DPA, BAA, SCCs, audit rights, residency commitments, and custom customer terms: customer agreement outputs.
SOC 2, ISO 27001, HIPAA certification, PCI, or equivalent compliance claims: completed audit, certification, or attestation outputs.
Contractual incident-notification windows, service credits, regulated support obligations, and breach-notice language: signed customer terms.
Customer-specific retention, legal-hold, export, deletion, or backup-destruction commitments: signed customer terms and operational acceptance.
Formal penetration-test reports or external vulnerability assessments: qualified security vendor or agreed internal/external assessment scope.
EU-only residency, customer-managed encryption keys, customer-controlled key destruction, and contractual key-custody guarantees: Enterprise deployment scope. Tenant-owned model-provider key custody is available for governed model routing and is the production default for cost-bearing model capacity, but it is separate from residency and encryption-key controls.

DPA and contract terms

Use the customer agreement packet for DPA, BAA, and contracting workflows. A customer-facing pack prepares the facts needed for that packet:

Item	Platform evidence	Customer agreement output
Data roles	Plain-language description of whether General Augment acts as a service provider/processor for app-provided content in the proposed integration.	Final controller/processor role language in a DPA or services agreement.
Data categories	Inventory of prompts, responses, user identifiers, memory facts, tool inputs/results, traces, usage metadata, audit rows, and support data.	Customer-specific regulated data terms, health-data terms, financial-data terms, or special-category data commitments.
Purpose of processing	Statement that customer content is used to operate the tenant’s agent, execute approved tools, provide support, debug incidents, and meter usage.	Contractual purpose limits and permitted-use language.
Transfers and subprocessors	Current service and subprocessor inventory with regions where known.	SCCs, transfer impact assessments, negotiated subprocessor notice periods, or audit rights.
Retention and deletion	Current technical retention/deletion matrix with backup caveats.	Binding retention schedule, backup purge SLA, legal hold, or customer-specific deletion window.
Security measures	Summary of current technical controls and evidence artifacts.	Contractual security exhibit and any customer-specific minimum controls.

HIPAA mode is a technical guardrail that can apply stricter PII filtering, disable durable conversation-history persistence for health projects, drop raw tool payload persistence where configured, and add health-data disclaimers. Regulated claims come from the accepted customer agreement and launch packet.

Subprocessor inventory

Maintain a dated subprocessor inventory before sending the pack. The inventory should separate required platform providers from optional customer-enabled providers.

Provider category	Current diligence posture
Google Cloud Platform	Hosted launch baseline for core API, database, cache, KMS, secret storage, artifacts, and managed infrastructure. Document region, service list, and backup posture.
Vertex AI Gemini and Vertex embeddings	Current GCP-first model and embedding path for the launch baseline. Document region/configuration where supported.
Public docs, dashboard, and status surfaces	Confirm live hosting and analytics configuration before sending a customer list. Do not imply tenant API data is processed by a public docs host unless live configuration proves that.
Optional model providers	List only providers enabled for the customer or deployment, such as OpenAI, Anthropic, or Perplexity, and mark unused providers as not enabled.
Optional auth, billing, email, messaging, and observability providers	Include providers such as Clerk, Stripe, Resend, Langfuse, WhatsApp/SMS, or Telegram only when configured for the customer’s workflow.
Customer-owned tool backends	Identify APIs called by generated tools or app-owned execution. General Augment should document the auth proxy or app-owned execution boundary, not claim control over the customer’s providers.

Before distribution, verify the inventory against production configuration and remove unused providers. Include vendor purpose, data categories, region/residency notes, security documentation links, and whether the provider receives customer content, metadata only, or no tenant data.

Privacy and data use

General Augment should include a privacy statement covering these current positions:

Customer request content, assistant responses, tool inputs/results, traces, logs, and memory facts are not used to train or fine-tune General Augment models by default.
Customer content is used to operate the requested agent turn, execute approved tools, provide memory recall where configured, debug incidents, prevent abuse, support customers, and meter usage.
Aggregate operational metrics such as latency, error rates, status codes, token totals, and cost totals may be used for reliability and capacity planning.
Support access should be scoped to the reported issue and should prefer response IDs, trace IDs, usage metadata, audit rows, and sanitized repros over raw customer content.
Apps should not send secrets, access tokens, private keys, or raw credentials in prompts, request metadata, memory metadata, tool inputs, traces, or analytics events.

When model or tool providers are enabled, their own configured account, region, and data-use terms apply to the minimum context needed for the requested turn or action.

Security policy

The security policy in the diligence pack should describe current platform controls without overstating audit maturity:

App backends call POST /v1/responses with project-scoped API keys kept server-side.
Project API keys are hashed before storage and returned only once at creation time.
Public browser and mobile clients should call the developer’s backend, not General Augment directly with a project key.
General Augment uses tenant/project/user scoping for API calls, memory, tools, traces, usage, and audit rows.
Delegated tool credentials are resolved server-side from configured credential storage and are not exposed to the model.
The auth proxy strips untrusted auth headers, injects configured auth server-side, rejects tenant/user/provider identity overrides, and records redacted audit rows.
Prompt isolation, pre-execution guards, network boundaries, tool allowlists, approval gates, rate limits, and audit logging work together to reduce agent action risk.
Persisted data in the hosted launch baseline uses managed Google Cloud encryption at rest, and public endpoints should be called over HTTPS.

See Security for the fuller customer-facing security description and Prompt Injection and Source Content for untrusted source-content handling.

Access control

Prepare an access-control packet that covers human, service, and customer access:

Area	Current control to document	Evidence to prepare
Customer API access	Project-scoped API keys, server-side storage, key rotation, masked key listing, and revocation.	Redacted key-management screenshots or API responses, rotation runbook, and sample customer backend secret-storage guidance.
App user scoping	The `user` field scopes memory and tenant-user behavior for `/v1/responses`.	Sample request/response with user ID redacted, memory isolation test output, and support-bundle example.
Team/operator access	Least-privilege production access, MFA, named admins, and access-review cadence.	Dated admin roster, role list, access-review signoff, offboarding checklist, and break-glass process.
Service access	Workload/service identities for infrastructure and provider access.	Service account inventory, high-level IAM summary, and secret access policy without printing secret values.
Support access	Issue-scoped support lookup through response IDs, trace IDs, usage records, audit rows, and sanitized customer repros.	Support workflow, redacted trace lookup, and customer consent process for raw content review.

Do not send raw secrets, raw customer content, personal mailbox exports, or unrestricted operator logs as diligence evidence.

Logging, traces, and audit

General Augment should present logging and audit as an operational control, not as a formal compliance attestation.

Current platform evidence can include:

Response IDs and trace IDs returned from /v1/responses.
W3C traceparent and tracestate propagation for app-side observability.
Token usage, latency, model metadata, cost metadata when available, and plan-limit events.
PII-redacted tool-call audit rows, including approval status where applicable.
Memory store, search, profile, single-memory delete, and user-memory purge receipts.
Usage rollups, raw usage events within lookup windows, and budget/rate-limit reasons.

Prepare redacted examples that show enough structure to prove observability without showing prompts, raw tool payloads, credentials, API keys, or customer secrets.

Incident response

A customer diligence pack can include an incident-response policy and a blank incident timeline. Include contractual notification windows or service credits when those terms are signed.

Suggested incident artifact set:

Severity definitions for availability, security, privacy, data integrity, and billing incidents.
Intake paths, including support@generalaugment.com for GA customers.
Triage checklist for /health/ready, /v1/responses, memory, tools, auth, budget, trace lookup, and public status surfaces.
Timeline template with detection time, affected projects, user impact, response IDs, trace IDs, audit IDs, mitigation, customer communication, root cause, corrective actions, and closure owner.
Post-incident review template with evidence links and prevention items.

Customer agreement terms own breach-notification timing, regulated incident handling, customer audit rights, and financial remedies.

Disaster recovery and business continuity

Document the current disaster-recovery posture plainly:

The hosted launch baseline runs in Google Cloud us-central1.
Cloud SQL automated backups and point-in-time recovery are currently documented with seven retained backups and seven days of transaction logs for the launch baseline.
Deleted primary-store data can remain recoverable in backups/PITR during the backup window.
Customer-selectable region pinning, EU-only residency, multi-region active-active failover, and customer-controlled key destruction are Enterprise deployment options.

Evidence to prepare:

Current backup/PITR configuration proof with secret values removed.
Restore-drill result, date, owner, recovery target, and gap list.
Dependency inventory for API, database, cache, KMS, secrets, model provider, embeddings, dashboard, docs, and status surfaces.
Manual continuity checklist for customer communication and temporary degraded-mode operation.

Formal RTO/RPO commitments require operational acceptance and signed terms.

Data retention and deletion

The diligence pack should include a technical retention matrix and any customer-specific retention terms:

Data class	Current technical posture to document
Request and response content	Persisted only where needed for the product path, debugging, support, memory, traces, or configured retention. State the specific customer/deployment setting when sending a pack.
Memory facts	Tenant/project/user scoped. Single-memory delete and user-memory purge remove scoped rows from primary stores after commit and produce audit receipts.
Tool inputs and results	Redacted/sanitized for audit where applicable. Raw payload persistence depends on configured product path and should be documented per deployment.
Usage, billing, security, and audit records	May remain as operational records for metering, fraud prevention, incident response, security, and financial reconciliation.
Backups/PITR	Deleted primary-store data can remain recoverable during the documented Cloud SQL backup/PITR window.
Project archive	Archive is a status change, not a hard delete.

Broader purge, backup-destruction, or regulated retention guarantees belong in signed customer terms.

Vendor-risk questionnaire library

Prepare a standard questionnaire library with short, current answers and evidence links. Recommended sections:

Questionnaire area	Standard answer shape
Company and product overview	General Augment is the agent backend for your app. App backends call `POST /v1/responses` and can add memory, tools, approvals, usage, traces, and audit surfaces.
Data collected	Prompts, responses, app user identifiers, memory facts, tool inputs/results, traces, usage metadata, audit rows, support metadata, and project configuration depending on enabled features.
Training use	Customer content is not used to train or fine-tune General Augment models by default.
Encryption	Managed Google Cloud encryption at rest for hosted launch baseline services; HTTPS for public endpoints.
Access controls	Project-scoped keys, server-side credential handling, operator least privilege, MFA/access-review evidence where available.
Logging and monitoring	Response IDs, trace IDs, usage events, budget/rate-limit events, and PII-redacted tool-call audit rows.
Incident response	Internal policy and support intake can be provided; contractual notification requires signed terms.
DR/BCP	Current backup/PITR evidence can be provided; formal RTO/RPO requires signed terms.
Certifications	Attach SOC 2, ISO 27001, HIPAA, or public compliance attestations when they are included in the approved customer packet.
Subprocessors	Dated provider inventory should be attached and verified against live configuration before distribution.

Customer review checklist

Before sending this pack to a customer:

Confirm the date, owner, and deployment scope of every artifact.
Verify the live production subprocessor and service inventory.
Remove unused optional providers from customer-specific materials.
Redact secrets, API keys, tokens, credentials, raw prompts, raw tool payloads, and personal data that is not needed for diligence.
Confirm the app integration path: app-owned execution or delegated General Augment tools.
Include /v1/responses request/response examples with project key and user values redacted.
Include current Security, Status and Readiness, API Stability, Support, and Prompt Injection docs.
Label draft policies as drafts until approved.
Label self-produced evidence as self-produced evidence, and attach third-party attestations when available.
Route DPA, BAA, SCCs, audit rights, regulated workflows, retention commitments, incident-notification windows, and SOC 2/ISO/HIPAA claims through the customer agreement or approved audit provider.

Suggested pack folder

Use a simple folder structure so customers can review the material quickly:

general-augment-security-pack/
  00-readme-and-scope.md
  01-product-security-overview.md
  02-v1-responses-data-flow.md
  03-privacy-and-data-use.md
  04-subprocessor-inventory.md
  05-access-control-evidence-redacted.md
  06-logging-traces-and-audit-examples-redacted.md
  07-incident-response-template.md
  08-dr-and-backup-summary.md
  09-retention-and-deletion-matrix.md
  10-vendor-risk-questionnaire.md
  customer-agreement/
    dpa.md
    baa.md
    soc2-iso-evidence.md

Every file should include “current as of” date, owner, source system, and whether it is self-produced, customer-specific, agreement-backed, or third-party-attested.