Tenant isolation via row-level security
Every tenant-scoped record in AgentHub carries an organization identifier, and every database query is executed under a session that has set the current organization context. Postgres row-level security policies enforce that no row outside the current organization can be read or written, regardless of the SQL emitted by application code. This is enforced at the database engine, not in the ORM, so a bug in our application layer cannot bypass it.
Migrations cannot disable row-level security on tenant-scoped tables without a compensating policy. Integration tests assert that a synthetic “cross-tenant” user cannot read or write across the boundary.
Audit-event hash chain
Every consequential action — agent installation, connector authorization, approval decision, run, override, billing-impacting event — is written to an append-only audit log. Each entry is hashed together with the hash of the previous entry, forming a tamper-evident chain. Customers (and our security team) can verify the chain end-to-end, and any altered or missing entry causes the chain to fail to replay.
The chain head is published into the audit export so customers can pin a chain state at the time of export and detect any after-the-fact tampering.
Hash-pinned approvals
When an agent intends to take an external action (send a message, write to a ticket, move money, run code), the action's canonical request payload is hashed and recorded with the approval request. The approver sees the exact payload that will be executed, and the platform refuses to execute any payload whose hash does not match the approved one. This eliminates a class of “preview vs. action” spoofing where a model proposes one thing and executes another.
Approval policies are configurable per agent and per tool, with optional dual control for higher-risk actions. Approval decisions are recorded in the audit chain.
Scope-limited connectors
Connectors to third-party systems request only the OAuth scopes the agent actually needs and are authorized at the Workspace level. Tokens are issued with the shortest practical lifetime, refreshed transparently, and revoked when an agent or connector is disabled. Connector calls are subject to per-Workspace rate limits and budget caps, and connector activity is recorded as audit events.
We do not share Workspace credentials across organizations, and connector tokens are never returned to the model context.
Secret rotation through a managed secret manager
Application secrets — database credentials, signing keys, OAuth client secrets, model-gateway keys, webhook signing secrets — are stored in a managed secret manager and injected into runtime environments at start-up. Secrets rotate on a defined schedule and on demand if a compromise is suspected. No secret is committed to source control; pre-commit hooks and CI scanners enforce this. We separate human and machine identities, with human access requiring SSO and step-up MFA.
Encryption
All traffic between clients and the Service is encrypted with modern TLS, with HSTS and certificate pinning at the edge. All customer data at rest — relational, object, vector, and backup — is encrypted with provider-managed keys backed by hardware security modules. Per-Workspace key wrapping is available on enterprise plans.
No raw card data on our systems
Card numbers, CVCs, and full PAN data never touch our servers. The card-payments processor handles tokenization in the browser; we receive only opaque tokens and last-four/brand metadata. As a result, AgentHub itself is not in scope for storage of cardholder data, and we limit the systems that even need to talk to billing APIs.
Identity, access, and session management
Customer accounts support email/password with strong hashing today, with OAuth and two-factor authentication on the roadmap. SAML SSO and SCIM provisioning are available on enterprise engagements. Sessions are stored in HTTP-only cookies with idle and absolute timeouts; workspace administrators can request session invalidation through support while in-product revocation ships.
Internally, MVS personnel use SSO, MFA, just-in-time elevation, and audited break-glass procedures. Production access is logged and reviewed.
Code execution sandbox
Agents that generate and run code do so inside ephemeral, network-restricted sandboxes provisioned per run. The sandbox cannot reach internal services, has a short wall-clock budget, and is destroyed at end of run. Filesystem and process isolation prevent one Workspace's sandbox from observing another's.
Data deletion on organization termination
When a Workspace is terminated — whether by the customer, by us for breach, or because a subscription has ended after the grace period — we run a purge job that removes Customer Content from the relational database, the vector store, the object store, the audit-export bucket, and any caches. The purge is recorded as a final audit event. Backups containing the purged data roll out of retention within the standard backup-retention window (no later than 35 days from purge), after which the data is unrecoverable.
Backups and disaster recovery
Production data is backed up at least daily, with point-in-time recovery for the relational store. Backups are encrypted and stored in a region separate from the primary read/write region. We test restore procedures on a regular schedule and document recovery point and recovery time objectives in our DPA appendices for customers under signed agreements.
Logging, monitoring, and incident response
We collect application, infrastructure, and security logs into a centralized pipeline with tamper-evident retention. Anomaly detectors and alerting rules raise tickets to the on-call rotation; high-severity events page within minutes. We maintain an incident response runbook, exercise it on a regular schedule, and notify affected customers of confirmed security incidents in line with our contractual commitments.
Software supply chain
Dependencies are pinned by lockfile and scanned by automated tooling for known vulnerabilities, license drift, and typosquatting. CI requires all checks to pass before merge, and production deploys require a signed release. Build artifacts and container images are signed and verified at deploy time.
Personnel security
MVS personnel sign confidentiality agreements, complete annual security and privacy training, and receive only the access required for their role. Access is revoked promptly on role change or departure. Background checks are conducted where permitted by law.
Vulnerability disclosure
We welcome responsible-disclosure reports. If you believe you have found a security vulnerability or a data-handling issue, please write to security@mvsagents.ai with steps to reproduce, the affected URL or asset, and any supporting evidence. You may PGP-encrypt your message; on request we will provide our current public key. We commit to acknowledge reports within two (2) business days, keep you updated on remediation, and to refrain from legal action for good-faith research that:
- Does not access, modify, or delete data belonging to other customers.
- Does not degrade the Service or pivot beyond what is needed to demonstrate impact.
- Gives us a reasonable opportunity to fix the issue before public disclosure.
- Complies with applicable law.
We do not currently operate a paid bug bounty program; we may, however, recognize significant disclosures publicly with the reporter's permission.
Audits and certifications
We are pursuing SOC 2 Type II and ISO/IEC 27001 attestations. Customers under NDA may request our latest security documentation, including penetration-test summaries, business-continuity plan, and policy library, by contacting security@mvsagents.ai.
Related pages
AgentHub is operated by MVS Holdings. Effective date: May 15, 2026.