Trust & Security
Security practices
What Oconee Runtime does today to protect access, data and evidence. Where a control is provided by our infrastructure providers rather than by Oconee directly, this page says so.
Identity and access
- Authentication
- Accounts authenticate with email and password or, where an organization enables it, Google sign-in. Passwords are hashed before storage; Oconee Runtime never stores them in a recoverable form.
- Multi-factor authentication
- Time-based one-time password (TOTP) and email-based second factors are supported. Organizations can require a second factor for all members, and it is required on paid plans.
- Single sign-on
- Organizations can connect an OpenID Connect identity provider, bound to a verified email domain, with optional just-in-time provisioning. Provisioned users never receive the owner role.
- Role-based access control
- Organization members hold one of three roles — owner, admin or viewer — and permissions are checked against that role on the server for every request, not in the interface alone.
- Administrative access
- Access to platform administrative functionality is restricted to authorized platform operators and requires a second factor. Requests that do not authenticate are rejected before any permission check runs.
- API keys
- Programmatic access uses organization-scoped API keys that are stored only as hashes, shown once at creation, and can be given an expiry.
Tenant separation
- Organization scoping
- Every authenticated request resolves to an organization, and access is checked against that organization's membership before data is returned. Data belonging to one organization is not served to another.
- Network isolation
- The production database and cache accept connections only from Oconee Runtime's own services. Neither is reachable from the public internet.
Encryption
- In transit
- Traffic to the Oconee Runtime application, marketing site and API is served over HTTPS/TLS. Responses carry standard hardening headers, including strict content-type handling, framing restrictions and a referrer policy.
- At rest
- Customer data is held in managed PostgreSQL and object storage operated by our infrastructure providers, which encrypt stored data at rest.
- Integration credentials
- Credentials for connected services — identity provider secrets, notification integrations and second-factor secrets — are encrypted with AES-256-GCM before they are written to the database.
Auditability and monitoring
- Append-only audit logging
- Administrative and platform actions are written to an audit log that the database itself refuses to modify or delete. Records are chained with SHA-256 so that a removed or altered entry is detectable rather than invisible.
- Security event recording
- Policy decisions on AI activity — allow, warn, block and redact — are recorded with the context that produced them, so a decision can be reviewed after the fact.
- Application monitoring
- Errors and performance are monitored through a third-party service configured not to transmit personal data by default, with sensitive fields redacted before anything is sent.
- Export for external review
- Organizations can export their event data, including in SIEM-ready NDJSON and CEF formats, for retention or analysis in their own tooling.
Data minimization and retention
- Metadata over content
- Oconee Runtime is designed to capture the metadata needed for governance and evidence without unnecessarily retaining sensitive content. Prompt text, source code, secrets, credentials, clipboard contents and payment details are scrubbed from event payloads, logs, exports, background jobs and error reports.
- Configurable retention
- Retention is set per data type rather than as one blanket window, with defaults by plan and custom windows for enterprise agreements. Legal holds can suspend deletion for specific data.
- No AI model training
- Customer prompts, responses, repositories and organizational data are not used to train public or proprietary AI models.
- Backups
- Production data is backed up on a schedule, and backup runs are recorded and monitored.
Secure development
- Automated security scanning
- Every pull request and a nightly job run secret detection, dependency vulnerability auditing, static analysis and infrastructure-as-code scanning against the codebase.
- Dependency management
- Dependencies are pinned through a committed lockfile, installed with an immutable install in continuous integration, and audited for known high-severity vulnerabilities.
- Secrets handling
- Application secrets are supplied through the deployment platform's environment configuration and are not committed to source control. Committed files are scanned for credentials on every change.
- Change management
- Changes reach production through version control and an automated pipeline that runs the test suite, type checking and linting before deployment.
Architecture
Security architecture overview
A conceptual view of the trust boundaries and where data goes. Implementation detail is available under a vendor review rather than published here.
- 01
AI / agent activity
A coding agent, IDE assistant or browser AI tool attempts an action.
- 02
Oconee Runtime
The attempt is observed at the point of action.
- 03
Context + policy evaluation
Actor, agent, action, resource and context are evaluated against the organization's policy.
- 04
Decision
Allow, warn, block or redact.
- 05
Audit evidence
The decision and the context that produced it are recorded.
Boundary
Customer environment
Developer machines, browsers, IDEs and repositories. Extensions and the IDE integration observe AI activity here and send governance metadata to Oconee Runtime.
Boundary
Oconee Runtime
Policy evaluation, decision records, audit evidence and the administrative dashboard. Data is scoped to the organization it belongs to, and the database and cache are not reachable from the public internet.
Boundary
External integrations
Systems a customer chooses to connect — an identity provider for single sign-on, a notification destination, or their own SIEM receiving exported events. These are configured by the customer and are not required to run the platform.
Compliance
Oconee Runtime is not currently SOC 2 certified. Formal SOC 2 readiness is part of our compliance roadmap as the platform and customer base grow. Enterprise customers can contact us for current security documentation and review materials.
Security contact
To report a suspected vulnerability or raise a security concern, contact us through the Oconee contact form. Please include enough detail to reproduce the issue, and give us a reasonable opportunity to investigate and respond before disclosing it publicly.
Oconee Runtime does not currently operate a paid bug bounty programme. We read and investigate every report we receive, and we will keep you informed while we do.
Questions
Security FAQ
Is Oconee Runtime SOC 2 certified?
Oconee Runtime is not currently SOC 2 certified. SOC 2 readiness is part of the compliance roadmap.
How does Oconee Runtime protect customer data?
Access is scoped to the organization the data belongs to and checked on the server for every request. Traffic is served over HTTPS/TLS, stored data is held in managed infrastructure that encrypts it at rest, and credentials for connected services are encrypted before they are written to the database. Administrative and platform actions are recorded in an append-only audit log.
Does Oconee Runtime encrypt data in transit?
Yes. Traffic to the application, marketing site and API is served over HTTPS/TLS, and responses carry standard hardening headers including strict content-type handling, framing restrictions and a referrer policy.
Does Oconee Runtime encrypt data at rest?
Customer data is stored in managed PostgreSQL and object storage operated by our infrastructure providers, which encrypt data at rest. In addition, Oconee Runtime encrypts integration credentials — identity provider secrets, notification integrations and second-factor secrets — with AES-256-GCM before storing them.
Where is customer data stored?
Production application services, the database and the cache run in the United States. The web application and marketing site are hosted in the United States. A per-region or dedicated deployment can be discussed for enterprise agreements.
Does Oconee Runtime use subprocessors?
Yes. The current list, including what each provider receives and where it operates, is published at /trust/subprocessors.
Can Oconee complete a security questionnaire?
Yes. Enterprise prospects and customers can request questionnaire responses along with current security documentation through the contact form.
How does Oconee Runtime handle retention and deletion?
Retention is configured per data type rather than as a single window, with defaults that vary by plan and custom windows available for enterprise agreements. Legal holds can suspend deletion for specific data. Retention varies by data type and service function — contact Oconee for current retention details for your configuration.
Does Oconee Runtime support SSO and SAML?
Organizations can connect an OpenID Connect (OIDC) identity provider, bound to a verified email domain, with optional just-in-time user provisioning. SAML is not currently supported. If SAML is a requirement for your organization, contact us so we can discuss it.
Can Oconee Runtime export events to SIEM tools?
Yes. Event data can be exported in NDJSON and CEF, the formats commonly accepted by SIEM platforms, alongside CSV, JSON, XLSX and PDF. Export is initiated from the platform rather than delivered as a continuous live feed.
Last updated: September 7, 2026