Security & compliance
At a glance
- Multi-tenant isolation via
organisation_idon every DB query - 4 guardrail types: content safety, PII detection, response validation, audit logging
- Auth model: agents treated as ProjectX employees (same auth as human users)
- Rate limiting: Redis-based sliding window with circuit breaker
- Encryption: Data encrypted in transit (TLS) and at rest (provider-managed)
Why this matters
“Where does our data go?” and “How do you prevent data leakage between tenants?” are the first two questions in every enterprise security review. This page gives you the answers — with enough specifics to satisfy a CISO, not just a checkbox.
Authentication model
The platform uses three auth mechanisms depending on the API surface:
| Route prefix | Auth method | Who uses it |
|---|---|---|
/api/dashboard | ProjectX user auth token | CS teams, customer admins |
/api/internal | API key + Shipsy employee verification | Internal systems, AgentFleet builder |
/api/internal-dashboard | Basic Auth (Shipsy employee) | Internal ops |
/api/webhook | Per-provider HMAC signature | ElevenLabs, Twilio, Meta, etc. |
/api/callback | Provider-specific HMAC | External tool execution |
/mcp | API key (MCP_API_KEY) | External AI clients |
/api/public | None | Health checks only |
Agents are treated as employees in ProjectX’s auth system — they get the same identity, permissions, and audit trail as human users.
Multi-tenant isolation
Every database query includes organisation_id as a mandatory filter. There is no way for one tenant’s agent to access another tenant’s data, workflows, or job results.
Guardrails
Four guardrail types defined in data/guardrail/guardrails.json:
| Type | When it runs | What it does |
|---|---|---|
| content_safety | Pre-LLM (before the model sees input) | Detects toxicity, violence, hate speech, self-harm. Blocks or flags. |
| pii_detection | Post-LLM (after model response) | Detects and masks email, phone, SSN, credit card, physical address in agent responses. |
| response_validation | Post-LLM | Validates JSON format, required fields, content length. Ensures agent output meets schema expectations. |
| audit_logging | Post-LLM | Writes compliance and monitoring audit trail. Every LLM call, tool execution, and decision is logged. |
Rate limiting
Redis-based sliding window with automatic fallback:
| Window | Default limit |
|---|---|
| Per minute | 60 requests |
| Per hour | 1,000 requests |
| Per day | 10,000 requests |
Circuit breaker: After 5 consecutive failures to a provider, the circuit opens for 60 seconds (fail-fast instead of queuing timeouts).
Fail-open design: If Redis is unavailable, rate limiting falls back to an in-memory counter. The API continues to work in degraded mode rather than refusing all requests.
Rate limiting configuration is documented in agents-helper/rate_limiting.md.
Data residency
Data residency is controlled by the deployment mode:
| Deployment | Data at rest | Data in transit (LLM calls) |
|---|---|---|
| Cloud | AWS (Shipsy’s infrastructure) | Transits to Azure OpenAI / GCP / Anthropic |
| Hybrid | Customer’s infrastructure | Transits to cloud LLM provider |
| On-prem | Customer’s infrastructure | Stays on-prem (Llama/Mistral) |
For customers with strict data-residency requirements, the hybrid or on-prem modes ensure stored data never leaves their infrastructure. See Deployment modes for the decision framework.
Observability & audit trail
Three layers of logging ensure full auditability:
| Layer | What it captures | Retention |
|---|---|---|
| New Relic | Application health, error rates, latency | Per New Relic plan |
| Elasticsearch | Every API request, job execution, tool call | 1-2 months |
| Langfuse | Every LLM call: prompt, response, tokens, cost, latency | Per Langfuse plan |
Every agent action — from receiving a trigger to making an LLM call to executing a tool — is logged with timestamps, organization context, and cost data.
Webhook HMAC validation
External webhooks (ElevenLabs, Twilio, Meta) are validated using HMAC signatures:
- Each provider has its own webhook secret (e.g.,
ELEVENLABS_WEBHOOK_SECRET) - The platform computes the HMAC of the request body and compares it to the signature header
- Invalid signatures are rejected with 401
What CS needs for security reviews
When a customer’s security team asks questions, here’s where to find answers:
| Question | Answer |
|---|---|
| ”Is data encrypted at rest?” | Yes — PostgreSQL encryption at rest (AWS-managed or customer-managed keys) |
| “Is data encrypted in transit?” | Yes — TLS everywhere |
| ”How do you isolate tenants?” | organisation_id filter on every DB query, API-level auth |
| ”Do you mask PII?” | Yes — post-LLM PII detection guardrail masks email, phone, SSN, credit card |
| ”Where do LLM calls go?” | Depends on deployment mode — cloud (Azure/GCP), hybrid (cloud LLM only), on-prem (local models) |
| “Do you have SOC 2?” | Check with the security team for current certification status |
| ”What about GDPR?” | Data residency options support GDPR compliance; DPAs available |
| ”Can we audit agent decisions?” | Yes — full audit trail in Elasticsearch + Langfuse |
Sources
- agent-platform repo:
data/guardrail/guardrails.json - agent-platform repo:
app/auth/ - agent-platform repo:
app/middleware/ - agent-platform repo:
agents-helper/rate_limiting.md - See Deployment modes for data residency options
- See Observability for monitoring and logging details
Changelog
- 26 May 2026: Full content from GitHub repo exploration. Guardrails, auth model, rate limiting, tenant isolation.