Security

Governance

The BRICQS governance system records every privileged platform action in an append-only audit log, enforces approval workflows for sensitive operations, and surfaces policy violations as actionable alerts.

Audit log

All platform actions are recorded with actor, timestamp, affected resource, and outcome. The log is immutable — entries cannot be edited or deleted, even by platform admins.

Query the audit log via the API:

bash# Recent events for an org
curl https://api.bricqsai.com/v1/audit/org/<org-id>?limit=50 \
  -H "Authorization: Bearer <api-key>"

# Filter by resource (e.g. a specific deployment)
curl https://api.bricqsai.com/v1/audit/resource/<deployment-id> \
  -H "Authorization: Bearer <api-key>"

Each audit event includes:

actionNamespaced event name, e.g. deployment.create, secret.delete, api_key.revoke.actor_user_idUser or service account that performed the action.resource_idID of the affected resource (deployment, project, secret, etc.).resource_nameHuman-readable name of the resource at the time of the event.status"success" or "failure" — failed actions are also logged for forensic completeness.detailStructured JSON with action-specific context (e.g. old/new environment, error message).created_atUTC timestamp of the event.

Approval workflows

High-risk deployments (GPU workloads, production environment, max replicas > 2) can be gated behind an approval step. When an approval policy is active:

A deployment request enters pending_approval status instead of provisioning immediately.
An org Owner or Admin reviews and approves or rejects the request from the Governance panel.
Approved requests proceed to provisioning; rejected requests are logged with a rejection reason.
The requesting user receives a notification on approval or rejection.

bash# Approve a pending deployment
curl -X POST https://api.bricqsai.com/v1/deployments/<id>/approve \
  -H "Authorization: Bearer <admin-api-key>"

# Reject
curl -X POST https://api.bricqsai.com/v1/deployments/<id>/reject \
  -H "Authorization: Bearer <admin-api-key>" \
  -d '{"reason": "Exceeds GPU quota for this sprint"}'

Policy rules

Policy rules let you define conditions that trigger governance actions (flag, block, or alert) when a matching audit event occurs. Rules are configured per org in the Governance panel.

flagMark matching events in the audit log for review. No blocking action; useful for pattern visibility.blockPrevent the action from completing. The request is rejected at the API layer with a 403.alertRecord a governance alert visible in the Security panel. Can also trigger a webhook notification.

Note: Policy rules operate on audit events, not on inference content. They are an operational control layer, not a real-time content safety system.

Exporting the audit log

Export the full audit log for compliance reporting or SIEM ingestion:

bash# Export last 90 days as NDJSON
curl "https://api.bricqsai.com/v1/audit/export?days=90&format=ndjson" \
  -H "Authorization: Bearer <admin-api-key>" \
  -o audit-export.ndjson

Exports include all event types. For continuous forwarding to a SIEM, configure a webhook in Governance → Settings → Audit Webhook.