Security
Portablov brokers access to the systems that run your company.
That is the whole product, so security is the architecture rather than a hardening pass. This page describes what Portablov does today — and is explicit about what it does not yet have.
Current status
Portablov does not hold SOC 2, ISO 27001, or any other certification today. We will not claim otherwise. The controls below are implemented; the audits that attest to them are ahead of us. The data model already carries what those audits will need — per-tenant residency, append-only audit, role separation and key scoping — so readiness is a matter of evidence and time rather than re-architecture.
Tenant isolation
- Authorization is a property of the record
- Every tenant-scoped entity stores its organization id. Access is granted only after looking up a membership row for (this user, that organization) — an id supplied by the browser can name a tenant but can never grant access to one.
- Partitioned by tenant at the storage layer
- The production data model partitions on the organization id, so a query that omits the tenant has no partition to read rather than a filter to forget.
- Existence is not enumerable
- A request for an organization you do not belong to returns "not found", not "forbidden".
Credentials and secrets
- Never in the browser
- OAuth tokens and API keys are stored in a managed secret store. Connection records hold a reference, never the material, and no API response can return it.
- Envelope encrypted
- Credential material is encrypted with AES-256-GCM under a managed key. In production that key is a customer-scoped KMS key, so decryption is authorised per tenant.
- Least-privilege scopes
- Connectors request the narrowest scope that supports the operation and report the scopes they were actually granted so you can review them.
- Read-only until you approve a cutover
- Assessment, mapping and validation never write to either platform. The first write is gated behind a named approval that states exactly what will happen.
Access control
- Permissions, not role names
- Code checks a permission; roles are named bundles of permissions. That keeps the role model mappable to your IdP without touching authorization logic.
- Planning does not imply executing
- A migration manager can plan, map, validate and dry-run. Executing a cutover requires admin or owner and a recorded approval.
- Separation of duties
- Whoever requests a consequential step cannot approve it while another eligible approver exists.
Application security
- Sessions
- Server-side session records with HttpOnly, SameSite=Lax, Secure cookies. The store keeps only a hash of the session token, so a database disclosure yields no usable session.
- Passwords
- scrypt with OWASP-aligned parameters, per-user salt, constant-time comparison, and equivalent work performed for unknown accounts so response timing does not reveal registration.
- CSRF and origin
- Unsafe methods require a session-bound double-submit token and pass an origin check.
- Headers and CSP
- A strict Content-Security-Policy with no external script or connect origins, plus HSTS, frame-ancestors none, nosniff and a restrictive Permissions-Policy.
- Input validation
- Every request body and every agent tool argument is schema-validated before it reaches domain logic.
- Rate limiting
- Authentication, mutation and agent endpoints are separately limited.
The AI boundary
- The model is not the migration engine
- The Portablov Agent can read through structured, permission-checked tools and can propose changes. It cannot execute anything. There is no shell, no HTTP client, no cloud credential and no database handle behind it.
- Propose, preview, approve, execute
- A proposed action becomes a rendered preview with counts and a required role. A human approves; typed application code executes; the audit trail records both the human and the agent.
- Minimal data exposure
- Tools return derived counts, reasons and identifiers — not raw customer records.
Observability and audit
- Append-only activity history
- Every state change, override, approval, waiver and agent answer is recorded with actor, target, request id and timestamp.
- Redacted structured logs
- Logs are JSON with tenant and request correlation. A redaction pass strips credential-shaped keys and truncates oversized values, so customer record payloads cannot reach a log line by accident.
What we are building toward
These are on the roadmap and reflected in the data model, but are not available yet.
- SAML SSO and SCIM provisioning
- Customer-managed encryption keys
- Regional data isolation (EU and US)
- SOC 2 Type II
- ISO 27001
- Documented GDPR sub-processor and DPA program
- Independent penetration test reports
- Configurable audit export and retention