Information Security Policy

This policy documents how ERAG protects the confidentiality, integrity, and availability of customer data and of the systems that process it. It applies to the hosted ERAG service, its supporting infrastructure, the software development lifecycle behind it, and every person with administrative access to production. The controls described here are operationalized: each section names the mechanism that enforces it in the product or in our operating procedures, not an aspiration.

Self-hosted deployments of the open-source distribution run under the customer's own security program; this document governs the hosted service at erag.one.

• Ownership. A designated Security Officer (the platform operator) owns this policy, approves changes to it, and is accountable for the controls below.
• Review cycle. The policy and its controls are reviewed at least annually and after any material architecture change or security incident.
• Least privilege. Production access is limited to the operator role; there are no standing shared credentials, and operator endpoints require a dedicated operator key or a platform-administrator session over TLS.

Risk is managed as a continuous cycle, each stage backed by concrete procedure:

• Identify. Structured security review sprints inventory threats across authentication, tenant isolation, data lifecycle, money paths, ingestion, and egress. Findings are tracked to closure as engineering tasks.
• Mitigate. Fixes ship as code with regression tests; the control catalog in sections 4–10 is the current mitigation baseline.
• Monitor. A tamper-evident audit trail records security-relevant events (authentication, permission changes, admin actions, AI governance decisions); automated test suites and a retrieval-quality gate run on every change; runtime health and delivery/telemetry anomalies are reviewed by the operator.

• Authentication. Password sign-in with TOTP two-factor authentication; SAML 2.0 single sign-on and SCIM provisioning for enterprise tenants.
• Session security. Server-side sessions with revocation — administrators can terminate any active session immediately.
• API credentials. Scoped API keys with expiry and rotation; rotation kills the old secret instantly.
• Authorization. Role-based access (admin / editor / reader) plus granular per-user workspace permissions enforced at centralized authorization choke points. Document-level ACLs are enforced inside index queries — filtering happens in the retrieval engine itself, never as an afterthought on results and never delegated to the language model.

• In transit. All traffic to the hosted service is encrypted with TLS.
• At rest. Customer document blobs are encrypted at rest; stored third-party credentials (bank-feed tokens, connector secrets) and consumer financial data received from bank-data providers (bank-feed transaction lines) are encrypted with application-layer authenticated symmetric encryption (AES via Fernet) before touching disk.
• Tenant isolation. Every customer-owned row carries a tenant identifier and every query is tenant-scoped by construction; cross-account sharing happens only through explicit, capability-scoped grants.
• Payment data. Card processing is delegated to Stripe; ERAG never stores card numbers.
• Secrets handling. Operator-level secrets are write-only through the console (masked on read) and excluded from source control.

• Tested changes. Every change runs a full automated backend test suite (490+ tests covering authentication, isolation, entitlements, and money paths), lint, type checking, and a retrieval-quality evaluation gate before deploy.
• Reviewed dependencies. Heavy or optional dependencies are isolated behind guarded imports; the core runs with a minimal dependency surface.
• Hardened ingestion. Outbound connector and webhook traffic passes an SSRF egress guard; user-supplied content is treated as untrusted end to end; uploaded content passes moderation controls.
• Deployment. Deploys are scripted and repeatable; production configuration is managed through an authenticated operator console, not ad-hoc server edits.

• Security-relevant events — sign-ins, permission changes, key rotation, admin actions, data-source connections, and payouts — are written to an audit trail available to tenant administrators.
• AI activity is separately governed: policy enforcement at query and agent choke points produces decision receipts, an answer audit log, and a model-usage log, with a kill switch that halts AI activity tenant-wide (see section 9).
• Operational telemetry (job health, delivery events, error rates) is reviewed by the operator; anomalies feed back into the risk register of section 3.

• Reporting. Suspected vulnerabilities or incidents can be reported to security@erag.one or through the in-product support system; reports reach the operator directly and are tracked as tickets to resolution.
• Triage and containment. The operator can revoke sessions, rotate keys, disable connectors, suspend tenants, and halt AI activity immediately from the operator console.
• Notification. Customers affected by a confirmed breach of their data are notified without undue delay, consistent with the Privacy Policy and applicable law.
• Post-incident. Root cause is fixed in code with a regression test, and this policy is updated where the incident revealed a gap.

Because the product is an AI platform, AI-specific risk is treated as first-class: tenant administrators define enforceable governance policies (topic and tool restrictions, grounding requirements) that are applied at runtime inside the query and agent execution paths — with per-decision receipts, an auditable answer log, and a tenant-wide kill switch. Model routing never exposes raw upstream model identifiers to end users, and answers carry citations to the customer's own documents.

• Automated backups of application data with documented restore procedures, exercised through the operator console.
• The platform degrades gracefully: core retrieval works without external AI providers, so a provider outage does not take grounded answering down.
• Customer data is exportable on request, and deleted on verified deletion requests as described in the Privacy Policy.

Third-party processors are limited to what the service needs to operate (payment processing, email delivery, optional AI model providers, optional bank-data aggregation), each accessed over authenticated, encrypted APIs with the minimum necessary scope — e.g. read-only restricted keys where the provider supports them. The current subprocessor list is available on request at security@erag.one.

ERAG does not currently hold third-party certifications such as SOC 2 or ISO/IEC 27001; the control set above is aligned with those frameworks' objectives, and because the platform's core is open source, the enforcement code for the product-level controls in this document is publicly inspectable. Security questionnaires are answered at security@erag.one.