Security
A read-only look at your estate, and nothing more.
Portablov brokers access to the systems that run your company, so the security posture is the architecture rather than a hardening pass.
- The assessment is read-only
- Portablov reads your schema, records, users and automations. It writes nothing back to either platform — not during discovery, not during mapping, not ever, unless you later engage us to migrate and approve each step by name.
- Minimum scopes, shown to you
- Each connector requests the narrowest scope that supports the assessment, and reports back the scopes it was actually granted so you can check them against what you expected.
- Credentials never reach the browser
- OAuth material is held in a managed secret store, envelope-encrypted, and referenced by an id. No API response can return it, and nothing in the product can print it.
- Your estate is isolated from every other tenant
- Authorization is a property of the record, not the request: access is granted only after a membership lookup, and asking for another organisation returns "not found".
- Every action is on the record
- Overrides, waivers, approvals and agent answers are written to an append-only trail with the actor, the target and the time. You can see who decided what.
- The data is yours to delete
- Deleting an assessment removes the estate snapshot, the user assessments, the mapping proposal, the findings and the connection records in one action. The audit entry that records the deletion is all that survives.
Technical controlsisolation, encryption, CSP, CSRF, hashing, rate limiting, the AI boundary
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.
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.
Enterprise compliance certifications are not currently held. Contact us for the current security posture, our regional data residency model, or a DPA.