Security

General Augment assumes prompts are untrusted. Security is handled outside the model.

Five layers

1. Prompt isolation scans project prompts for tokens or passwords.
2. Pre-execution guards verify tenant, enabled tool, identity link, and input fields.
3. Network isolation restricts worker egress to approved internal services.
4. Tool permissions enforce action scopes, approvals, cooldowns, and per-tool limits.
5. Rate limiting and audit logging record every sensitive action with PII filtering.

Auth proxy

The agent never receives backend credentials.

Agent tool -> internal proxy -> credential vault -> developer API

Credential ownership

Choose the action boundary per integration:

Pattern	Who executes the side effect	Credential owner
App-owned execution	Your backend executes after reading a General Augment response, structured output, or action proposal.	Your app keeps user OAuth tokens and provider credentials in your own vault.
Delegated General Augment tools	General Augment executes an enabled tool during the agent turn.	General Augment resolves configured credentials server-side by project, user, and provider.

If your app already owns Gmail, Calendar, CRM, or other OAuth tokens, keep executing those actions in your backend. Pass summaries, drafts, or action proposals through /v1/responses, show your own confirmation UI, then use your app-held credentials to perform and record the side effect. Delegate later only after connecting General Augment credentials, identity links, allowlists, and approval UX.

For delegated built-in tools, credentials come from the General Augment credential vault or configured provider settings and are never model-visible. For generated OpenAPI/project-defined tools, the auth proxy or app backend resolves credentials server-side, strips agent-supplied auth headers, rejects tenant/user/provider identity overrides, and returns sanitized results.

Tool allowlists and credentials are separate controls: enabling a tool only makes it available to the managed agent runtime. Credentials, linked identity, and required approval must still exist before execution can complete.

Data protection

Customer request content, assistant responses, memory facts, traces, usage rows, audit rows, and project configuration that General Augment persists are stored in managed Google Cloud services for the hosted launch baseline. Cloud SQL PostgreSQL, Cloud SQL backups/PITR logs, Memorystore Redis, Secret Manager, Artifact Registry, and managed logging/storage services use Google Cloud encryption at rest with Google-managed or General Augment-managed keys unless a separate signed agreement says otherwise.

Credentials get stricter handling than ordinary agent context. Provider credentials, OAuth tokens, webhook secrets, and tool execution secrets are stored in Secret Manager or the General Augment credential vault. Project API keys are hashed before storage; after creation, General Augment returns only masked previews.

Tenant-owned model-provider key custody is available for governed model routing. Production tenants should use tenant-owned provider keys for cost-bearing model capacity unless the launch packet explicitly funds platform-managed capacity. This is not a customer-managed encryption key or compliance-control feature. Customer-managed encryption keys, customer-controlled key destruction, and contractual key-custody guarantees are Enterprise deployment commitments captured in signed terms. Public endpoints should be called over HTTPS, and app developers should not send secrets in prompts, metadata, memory facts, tool inputs, traces, or analytics payloads.

HIPAA mode

HIPAA mode is a technical guardrail. It applies stricter PII filtering, disables durable conversation-history persistence for health projects, drops raw tool payload persistence where configured, and adds health-data disclaimers to relevant replies.

SOC 2, ISO 27001, HIPAA, DPA, BAA, audit rights, customer-specific retention, residency, and regulated support commitments are represented through the accepted customer agreement and launch packet.

Audit logs should never contain raw access tokens, API keys, or user secrets. See Identity Linking for user resolution and Prompt Injection for untrusted source content handling. See Status and Readiness for the shorter launch-readiness summary.