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.