Security & Data

Security Overview

ActLoom implements a layered security model that is visible directly in the product and codebase: authenticated sessions for human users, scoped API keys for machines, company-aware authorization checks, encrypted secret storage, rate-limited sensitive endpoints, and a verifiable audit trail for important actions.

What this section clarifies

What is confirmed by the product

This page focuses on security controls that are actually implemented in the application, not generic SaaS promises.

What reviewers usually need

It gives security, procurement, and IT teams a compact explanation of identity, access, secrets, auditability, and integration hardening.

Where the boundaries are

It also distinguishes platform controls from customer responsibilities such as role assignment, credential hygiene, and integration operations.

Operational aspect	What to know in ActLoom
Best use of this page	Treat it as a product-security implementation summary, not just a policy statement.
Main questions answered	How identity, authorization, secrets, machine access, webhook delivery, and auditability are implemented in the product.
Who typically reads it	Security reviewers, procurement teams, IT, enterprise customers, and technical buyers.
Primary outputs	A concise implementation narrative that can support security review, diligence calls, or internal technical validation.

Identity & Sessions

Auth.jsJWT SessionsGoogle OAuthCredentials Login

Authorization & Tenant Access

Owner/Admin/Executive/MemberCompany Access ChecksProtected Routes

Secret & API Protection

AES-256-GCM Secret EncryptionSHA-256 Key HashingScoped API KeysRate Limits

Operational Integrity

Audit Hash ChainWebhook Signature SupportSSRF BlockingCSV Audit Export

Workspace Data & Audit Records

Fig 26. Security architecture — identity, workspace authorization, protected secrets, machine access controls, and verifiable audit history.

Identity

Auth.js with JWT sessions, email/password sign-in, Google OAuth, and optional enterprise SSO.

Authorization

Company-scoped access checks determine whether a user is owner, executive, admin, or member before protected actions run.

Secret protection

API keys and webhook secrets are stored as SHA-256 hashes; integration and SSO secrets are encrypted with AES-256-GCM before persistence.

Machine access

API keys are scope-checked and rate-limited before versioned machine endpoints allow access.

Input Validation

Sensitive settings and API endpoints validate request bodies and query params with Zod before processing.

Rate Limiting

Rate limiting is endpoint-specific rather than one global number: login, signup, SSO, report generation, classification, and API key flows each have their own thresholds.

Auditability

Sensitive actions are logged into a chained audit trail with sequence numbers, previous-hash linkage, and integrity verification support.

Webhook delivery controls

Outbound webhooks block private or loopback targets, use timeouts, and can attach HMAC signatures for live deliveries.

Identity, Secrets, And Auditability

The most useful way to read ActLoom security is by following the lifecycle of access and sensitive operations: a user authenticates, the app resolves workspace-level permissions, protected actions are executed with scoped checks, secrets stay encrypted or hashed at rest, and important events are written into an auditable chain.

Security Flow In The Product

Authenticate

Users sign in via credentials, Google OAuth, or workspace SSO when configured.

Authorize

APIs resolve workspace access such as owner, admin, executive, or member before protected actions proceed.

Protect

Secrets are encrypted or hashed, and machine access is gated by scope checks and rate limits.

Record

Critical and operational actions can be written into the audit chain for later verification and export.

Security area	What is implemented	Why it matters
User authentication	Credentials login uses bcrypt password verification; Google OAuth is supported; enterprise SSO is available through a per-company OIDC configuration.	Supports standard login, external identity, and enterprise onboarding paths without sharing one global IdP config.
Session enforcement	Protected routes such as `/dashboard`, `/onboarding`, and `/admin` are redirected to sign-in when no valid session is present.	Reduces accidental exposure of application surfaces to unauthenticated traffic.
Workspace authorization	APIs commonly use company access resolution to enforce workspace membership and elevated privileges for owners or admins.	Makes security decisions tenant-aware at the application layer.
Encrypted secret storage	Integration client secrets and SSO secrets are encrypted with AES-256-GCM using dedicated environment keys before storage.	Protects high-value third-party credentials if the database is exposed.
Hashed machine credentials	API keys and webhook secrets are not stored in plaintext after issuance; only a preview or prefix is retained for operators.	Limits blast radius if configuration records are queried or exported.
Audit chain verification	Audit events are linked by `previousHash`, `sequence`, and per-event SHA-256 hash, with a verification endpoint and export flow.	Helps demonstrate event integrity during audits, investigations, or customer due diligence.

Enterprise SSO in the current product

SSO is available as a workspace configuration, gated by plan. The current implementation requires a Pro plan, allows only owners and admins to manage the configuration, and never returns the stored client secret back to the browser once saved.

Endpoint or feature	Security behavior confirmed in code
Credentials sign-in	Rate limited per email and validated against stored password hashes.
SSO start / callback	Rate limited and backed by short-lived signed handoff tokens after IdP exchange.
Machine API	Requires `actloom_` API key format, validates scope, enforces expiry and revocation, and applies per-key rate limiting.
Webhook delivery	Rejects blocked destinations, uses timeout protection, and can attach `x-actloom-signature` for signed live deliveries.
Audit endpoints	Expose paginated log access, CSV export, and audit-chain verification to authorized workspace users.

Useful points for a security review

Do not describe ActLoom as using database Row Level Security unless you have separately validated that infrastructure layer; the application code confirms tenant-aware authorization checks instead.
API key management, webhook management, and integrations management are owner/admin actions, not general member capabilities.
The webhook test route is useful for reachability and diagnostics, but the current test route does not include the HMAC signature header used by live delivery code.
Audit export is available now as CSV; async export is explicitly not enabled in the current endpoint.

Shared Responsibility

Strong security posture still depends on how your team uses the platform. ActLoom can enforce access checks, encrypt secrets, and maintain audit records, but customers still control who gets elevated roles, where credentials are stored after issue, and which external endpoints are connected.

Area	ActLoom handles	Customer should handle
Workspace access	Protected session flows and company-aware authorization checks	Keep owner/admin access narrow and review memberships after staffing or vendor changes
Machine credentials	Key hashing, scope validation, expiry handling, and revocation support	Store plaintext keys in a secret manager and rotate them when environments or operators change
SSO and integration secrets	Encrypted persistence for stored secrets	Choose correct IdP settings, protect admin access, and remove stale client credentials
Webhooks	Outbound delivery controls, blocked-target protection, delivery diagnostics	Run a public HTTPS receiver, validate signatures where available, and make handlers idempotent
Audit readiness	Chained logging, verification, and export capabilities	Review events regularly and preserve exported evidence under your own retention obligations

Questions security reviewers usually ask

Which roles can manage integrations, SSO, API keys, and webhooks?
How are third-party secrets protected after they are saved into the workspace?
Can the audit trail be exported and can its integrity be checked later?
What protections exist against abusive machine access or unsafe webhook destinations?

What this page is and is not claiming

This docs page describes controls that are visible in the application and code paths reviewed in the product. It should not be read as a substitute for customer-specific security validation, deployment review, or independent legal advice.

Related Sections

Integrations/API

Use this when the security question involves API keys, webhooks, release gates, or third-party connections.

Team

Read this when access control questions are really about role design, owner assignment, and workspace administration.

Trust Center

Go here when security posture needs to be communicated selectively to customers or diligence reviewers.

Artifacts

Use this for the output view of audit trail exports, controlled evidence, and externally shared assets.

Ready to get started?

Join hundreds of companies using ActLoom to simplify AI Act compliance. Start your free assessment today — no credit card required.

Start Free Assessment View Pricing

Questions? Contact us at support@actloom.com

Operational aspect

What to know in ActLoom

Best use of this page

Treat it as a product-security implementation summary, not just a policy statement.

Main questions answered

How identity, authorization, secrets, machine access, webhook delivery, and auditability are implemented in the product.

Who typically reads it

Security reviewers, procurement teams, IT, enterprise customers, and technical buyers.

Primary outputs

A concise implementation narrative that can support security review, diligence calls, or internal technical validation.

Security area

What is implemented

Why it matters

User authentication

Credentials login uses bcrypt password verification; Google OAuth is supported; enterprise SSO is available through a per-company OIDC configuration.

Supports standard login, external identity, and enterprise onboarding paths without sharing one global IdP config.

Session enforcement

Protected routes such as `/dashboard`, `/onboarding`, and `/admin` are redirected to sign-in when no valid session is present.

Reduces accidental exposure of application surfaces to unauthenticated traffic.

Workspace authorization

APIs commonly use company access resolution to enforce workspace membership and elevated privileges for owners or admins.

Makes security decisions tenant-aware at the application layer.

Encrypted secret storage

Integration client secrets and SSO secrets are encrypted with AES-256-GCM using dedicated environment keys before storage.

Protects high-value third-party credentials if the database is exposed.

Hashed machine credentials

API keys and webhook secrets are not stored in plaintext after issuance; only a preview or prefix is retained for operators.

Limits blast radius if configuration records are queried or exported.

Audit chain verification

Audit events are linked by `previousHash`, `sequence`, and per-event SHA-256 hash, with a verification endpoint and export flow.

Helps demonstrate event integrity during audits, investigations, or customer due diligence.

Endpoint or feature

Security behavior confirmed in code

Credentials sign-in

Rate limited per email and validated against stored password hashes.

SSO start / callback

Rate limited and backed by short-lived signed handoff tokens after IdP exchange.

Machine API

Requires `actloom_` API key format, validates scope, enforces expiry and revocation, and applies per-key rate limiting.

Webhook delivery

Rejects blocked destinations, uses timeout protection, and can attach `x-actloom-signature` for signed live deliveries.

Audit endpoints

Expose paginated log access, CSV export, and audit-chain verification to authorized workspace users.

Area

ActLoom handles

Customer should handle

Workspace access

Protected session flows and company-aware authorization checks

Keep owner/admin access narrow and review memberships after staffing or vendor changes

Machine credentials

Key hashing, scope validation, expiry handling, and revocation support

Store plaintext keys in a secret manager and rotate them when environments or operators change

SSO and integration secrets

Encrypted persistence for stored secrets

Choose correct IdP settings, protect admin access, and remove stale client credentials

Webhooks

Outbound delivery controls, blocked-target protection, delivery diagnostics

Run a public HTTPS receiver, validate signatures where available, and make handlers idempotent

Audit readiness

Chained logging, verification, and export capabilities

Review events regularly and preserve exported evidence under your own retention obligations