Security Model
Identity, access control, auditability, and platform security by design.
Argy treats security as a platform pillar: identity, governance, traceability, and guardrails are designed into the product.
Identity & Access (IAM)
Passwordless-first authentication
Argy is passwordless-first:
- WebAuthn / Passkeys (primary)
- Magic link (onboarding, recovery, fallback)
- OIDC (Microsoft Entra ID, Okta, Google Workspace)
- SAML 2.0 (enterprise SSO)
- Device Flow (RFC 8628) for agents and terminals
Password authentication is explicitly disabled.
RBAC roles
Typical roles include:
PLATFORM_ADMINPLATFORM_ENGINEERPLATFORM_PMPLATFORM_USERCOMPLIANCE_APPROVER
Argy supports SCIM for provisioning users and groups.
Multi-tenancy & Data Isolation
Argy enforces tenant isolation at multiple layers:
- PostgreSQL: Row-Level Security (RLS) with
tenant_idon every table - Redis: per-tenant key prefixes
- API:
x-tenant-idandx-org-idvalidated on every request - Object storage: per-tenant partitioning
- LLM governance: quotas and filters per tenant and organization
Auditability
- Every action is logged with context (who/what/when/resource).
- LLM requests are traceable (user, model, tenant) with correlation IDs.
- Minimum retention: 90 days, exportable as CSV.
- Optional AES-256 encryption for request/response content.
Transport & Data Encryption
- TLS 1.2+ for all HTTP traffic
- AES-256 encryption at rest for credentials (and optionally for audits)
- JWT signed with RS256
- Short-lived sessions stored in Redis with TTL
Service-to-service Security
Internal service calls are protected with HMAC signing (timestamp + tenant + body) to prevent replay and tampering.
Kubernetes Hardening (Self-Hosted / On-Prem)
When deployed on Kubernetes, Argy services follow hardening best practices:
- Pod Disruption Budgets (PDB)
- Default-deny Network Policies with per-service rules
- Non-root containers, read-only root filesystem, dropped capabilities
- Anti-affinity to spread critical services across nodes
Security Scanning
Argy includes security tooling such as:
- Trivy vulnerability scanning (images, filesystem, IaC)
- Gitleaks secret detection
- SBOM generation
Execution Agents
Execution agents can run in SaaS-managed or self-hosted modes. They are protected by:
- HMAC (SaaS) or API key (on-prem)
- Isolated workspace per run (
/work/<runID>/) - Read-only filesystem (except
/tmpand the workspace) - Non-root execution (uid 1001)
To see how governance and guardrails translate into outcomes, browse the use cases.