Security at NoirGen Agent QA

NoirGen LLC has implemented application-level safeguards for NoirGen Agent QA. This page does not represent that the production service is deployed, that every planned provider control is active, or that any system is free from risk.

Local and repository-based verification can establish application behavior. It cannot, by itself, prove live Cloud Run identity, Cloud SQL isolation, Cloud Storage access, Secret Manager configuration, Cloudflare enforcement, hosted provider delivery, backup recovery, or public-route behavior. M28 owns deployment and recovery evidence.

Identity and tenant authorization

• Auth.js uses server-side database sessions, with an opaque token in an HttpOnly session cookie.
• Tenant operations derive the user from the current session and recheck organization and resource ownership server-side. Browser-supplied organization identifiers are lookup inputs, not authorization.
• Owner-only account and organization operations are reauthorized, and the application prevents demotion of the last organization owner.

Connector and credential protection

• Customer endpoint credential-header values are stored in an AES-256-GCM envelope with a random initialization vector, authentication tag, versioned key, and additional authenticated data bound to the organization and agent.
• Decrypted credential values are server-only and are not returned to the browser or sent to analytics and error monitoring by the application contract.
• The HTTP connector validates schemes, hosts, ports, DNS answers, connected peers, redirect destinations, methods, JSON shape, response size, header size, and timeouts. Production connector destinations are restricted to HTTPS on port 443, and loopback, private, link-local, metadata, multicast, and related unsafe addresses are rejected.

Browser, webhook, and internal-request controls

• Authenticated JSON responses use private, no-store behavior, and sensitive browser mutations use same-origin evidence in addition to authorization.
• Environment-aware security headers include content-security, frame, MIME-sniffing, referrer, permissions, cross-origin, and production transport protections. Their hosted behavior still requires M28 inspection.
• Durable application rate limits protect selected authentication, connector-test, draft-generation, and organization-creation operations. These do not replace edge or provider controls.
• Stripe webhook processing verifies the signature over bounded exact raw bytes and uses unique receipts and current-subscription reconciliation for replay and ordering safety. The implemented Stripe runtime supports explicit disabled, test, and live modes with fail-closed mode matching. Live configuration and provider behavior still require M28 production verification.
• Worker and scheduler routes implement exact identity and request contracts. Private Cloud Run IAM enforcement is a separate, not-yet-proven production boundary.

Selected customer-agent responses, knowledge, prompts, test definitions, and evaluation evidence are tenant-private product data. Browser read models intentionally omit selected response text, connector credentials, raw provider output, hidden model reasoning, and unrelated tenant data except where a specific authenticated product surface is designed to expose bounded evidence.

OpenAI calls use server-side credentials, structured output, bounded requests and responses, a pseudonymous safety identifier, no tools for evaluation, and store: false. Provider output is treated as untrusted and revalidated locally. The request setting does not establish zero provider retention or remove the need to review OpenAI's applicable terms and configured data controls.

PostHog product events are delivered server-side with HMAC-pseudonymous identifiers, a strict property allowlist, person profiles disabled, and GeoIP disabled. Sentry collection disables default personal data, cookies, request and response headers and bodies, database query values, and generative-AI inputs and outputs; a final scrubber removes user, request, and arbitrary extra objects.

These are application configuration controls. Hosted PostHog and Sentry ingestion has not yet been verified, and network-level metadata processed by a provider may be governed by that provider's own service terms.

The reviewed production design calls for:

• Cloudflare in front of a Google Cloud external load balancer and public web service;
• a non-public Cloud Run worker with authenticated Cloud Tasks delivery;
• private-IP Cloud SQL PostgreSQL and separate least-privilege service identities;
• private Cloud Storage with uniform access and public-access prevention;
• Secret Manager containers and runtime-specific access; and
• Cloud Logging, Cloud Monitoring, backups, point-in-time recovery, and recovery plans.

Those declarations do not prove deployment or operation. The application includes a fail-closed private Google Cloud Storage adapter, but no production upload has been exercised. The reviewed Secret Manager resources and numeric-version runtime mappings contain no secret values and have not been applied. Cloudflare rules, public TLS, hostname routing, and origin-bypass protection require live planning, application, and readback. Database recovery objectives are targets, not achieved uptime, recovery-time, or recovery-point guarantees.

This draft makes no claim of SOC 2 certification, HIPAA compliance, regulatory compliance, penetration-test certification, guaranteed uptime, guaranteed incident prevention, guaranteed data recovery, or complete protection against every vulnerability or attack.

Security is a shared and evolving process. Technical controls can reduce risk but cannot make Internet-facing software or third-party services risk-free. Evaluation findings are also probabilistic and are governed by the separate AI evaluation limitations.

Customers remain responsible for:

• using endpoints, accounts, data, and credentials they are authorized to access and test;
• limiting connector credentials to the minimum permissions needed and rotating or revoking them when appropriate;
• deciding whether prompts, knowledge, agent responses, and support messages are appropriate for the service and its configured providers;
• maintaining the security and availability of their own agent endpoint;
• reviewing organization membership and promptly removing access that is no longer needed;
• not sending passwords, payment-card numbers, unnecessary secrets, or regulated data for which the service has not been reviewed and contractually approved; and
• independently reviewing important QA findings rather than treating an automated result as infallible.

Additional restrictions appear in the Acceptable Use Policy.

Send a concise report to [email protected] with the subject Security report. Include the affected route or feature, observed behavior, date and time, and safe reproduction steps. Do not email passwords, API keys, connector credentials, session tokens, exploit payloads containing customer data, or payment-card details.

The mailbox's activation, monitoring owner, secure evidence-transfer path, triage procedure, disclosure policy, and response targets remain launch prerequisites. No response or remediation deadline is promised by this draft.