Security at Isovel

Isovel reads from your Business Central tenant and, after the trial, writes back to it. That’s a meaningful trust ask. This page describes how we earn it.

We’d rather show our work than make claims. The architecture, controls, and roadmap are below. If you want to dig deeper, email support@getisovel.com.

The trust primitives

Four controls are non-negotiable for every Isovel deployment, today and forever:

1. Shadow mode is the default trial. During the 30-day trial, Isovel is read-only. We pull your BC data, build forecasts and recommendations, and show you the dashboards. We do not write anything back to BC. Write-back unlocks at conversion to paid.
2. Approval-gated by default. Every write-back action is approval-gated when you first turn on paid mode. As you build trust with the agent’s recommendations, you can graduate specific action types to auto-execute — but the approval-gate is the default, and you can restore it on any action type at any time.
3. Idempotent writes. The agent’s writes are designed so a re-run never creates duplicate orders or duplicate forecast entries. If a write retries because of a transient error, the result is the same as a single successful write.
4. 24-hour rollback. Every write-back action — purchase order, transfer order, demand forecast entry — can be reversed for 24 hours after it’s written. One click, fully audit-logged.

These four are written into the product, not into the marketing copy. They don’t go away as the agent earns autonomy; the autonomy is the rate at which approval-gates loosen, not the rate at which the primitives disappear.

Architecture

Isovel runs on Google Cloud Platform. Production data lives in us-central1 (Iowa, USA).

• Compute. Cloud Run, isolated by service. Services don’t share execution context or credentials.
• Application database. Cloud SQL for PostgreSQL — encrypted at rest, automatic backups, point-in-time recovery.
• Data lake. Customer BC snapshots stored as Parquet in Google Cloud Storage, encrypted at rest, with object-level access logging.
• Secrets. Google Secret Manager. No plaintext secrets in source, in environment files at rest, or in container images.
• Network. All public surfaces are TLS-only (TLS 1.2+; TLS 1.3 preferred). Internal service-to-service traffic uses Google’s encrypted backbone with workload identity.

Per-service documentation lives in our internal architecture docs; sub-processor and infrastructure summaries are reflected in the privacy policy.

Authentication

• Customer authentication (GA target). Single sign-on via Microsoft Entra through WorkOS. Microsoft Entra SSO is table-stakes for the BC buyer.
• Authentication today (trial). Firebase Auth during the shadow-mode trial; migration to WorkOS is committed before paid GA.
• MFA. Required for Isovel employees. Strongly recommended (and SSO-enforced via your Entra policies) for customer users.
• Service-to-service. Workload identity within Google Cloud; no static service-account keys in CI or runtime.

Business Central access

We connect to your BC tenant through Microsoft’s standard OAuth flow.

• You authorize us. The OAuth grant happens in your tenant, under your administrator. We never touch BC admin credentials.
• Least privilege. We request the minimum permissions needed to read planning-relevant data and (post-trial, on your separate authorization) to write back specific entities — purchase orders, transfer orders, demand forecast entries, requisition lines. We do not request access to data we don’t use.
• You can revoke at any time. Revoking the OAuth grant from BC immediately cuts our access. Within the same business day, we stop reading; within 30 days, we delete cached data per the privacy policy schedule.

Encryption

• In transit. TLS 1.2+ for everything inbound to Isovel. TLS for everything between Isovel and Google services. TLS for BC connections.
• At rest. Google-managed encryption keys on Cloud SQL, Cloud Storage, and Secret Manager. Customer-managed encryption keys (CMEK) are on the GA roadmap for customers who require them.

Audit logging

Every action the agent takes is written to a per-tenant audit log:

• Forecast updates — model run ID, inputs, output range, the SKUs touched.
• Recommendations — when surfaced, when approved, when rejected, by which user.
• Write-backs — every PO, transfer, forecast entry, or requisition line written, with full payload, BC response, and the user who approved it.
• Rollbacks — every rollback within the 24-hour window, with reason.

The audit log is exportable and immutable for the retention window described in the privacy policy. Operationally, this means an internal-audit or customer-IT review of “what did the agent do, on what authority, with what result” is one query away.

People and process

• Least-privilege access. Isovel employees access customer data only when needed for support, debugging, or under your written instruction. Access is logged. We’re a small team today and most engineers have no production access by default.
• Background screening. Standard pre-employment screening for all roles with potential production access.
• Training. Security and privacy training on hire and at least annually.
• Vendor review. Sub-processors are reviewed before onboarding and on material change. The working list is in the privacy policy.

SDLC

• Source control. GitHub with branch protection on main. No direct pushes; review required.
• CI/CD. GitHub Actions builds container images, signs them, and deploys via Terraform. Infrastructure changes flow through the same review process.
• Dependency scanning. Automated vulnerability scanning on dependencies and container images. We patch criticals on a defined timeline (target: 7 days for criticals, 30 for highs).
• Secret hygiene. Pre-commit and CI checks for accidental secret commits.

Vulnerability disclosure

If you find a vulnerability:

• Email support@getisovel.com with details and a way to reproduce.
• Please don’t publicly disclose until we’ve had a reasonable window to fix (we aim for 90 days; faster for criticals).
• Don’t access data that isn’t yours, don’t disrupt service for other customers, and don’t run automated scans that materially affect availability.
• We acknowledge reports within two business days and will keep you posted on the fix. Researchers acting in good faith under this policy will not be pursued legally; we don’t currently run a paid bounty program.

Incident response

If we have a security incident that affects your data, we’ll notify you without undue delay — and within the timelines required by applicable law and your MSA. Our notice will describe what happened, what data was involved, what we’ve done, and what you can do.

We run incident drills periodically. The plan covers detection, containment, eradication, recovery, and post-incident review.

Compliance roadmap

• SOC 2 Type 1 — in progress. Target: complete before GA. We’ll publish the report under NDA on request.
• SOC 2 Type 2 — committed for the period following GA.
• ISO 27001 — under evaluation; not a launch commitment.
• HIPAA — not in scope. Isovel is not designed to process protected health information.
• EU data residency — Phase 2. US + Canada at launch.

Sub-processors

Listed in the privacy policy. Material changes are notified in advance to customers under contract.

Customer responsibilities

Security is a shared model. The strongest controls on our side don’t substitute for these on yours:

• Enforce SSO and MFA in your Microsoft Entra tenant.
• Use Entra conditional access for risk-based controls if you have them.
• Limit which BC administrators can authorize Isovel.
• Revoke access when an employee leaves.
• Use Isovel’s approval-gates rather than graduating actions to auto-execute until you’ve confirmed the agent’s track record in your environment.

Contact

Security questions and vulnerability disclosure: support@getisovel.com General contact: support@getisovel.com