A security model for an AI-native people platform

Start with the action path

Security copy is often written as a list of controls. Buyers need the action path: who is acting, which boundary authenticates them, which service authorizes the exact action, what data is touched, and what gets recorded.

Perelan Security is organized around that path.

Authenticate at the boundary

The gateway validates the user session and handles cookie and CSRF behavior for browser writes. Services should not receive browser session cookies and should not trust hidden front-end controls.

Carry signed identity to services

Domain services need to know who is acting without handling the session token themselves. Signed internal identity lets the gateway and service-to-service calls carry a subject and request context.

Authorize in the domain

The people service, recruiting service, time-off service, access service, and others own their domain rules. A Slack button or AI tool should still reach that domain service as a specific actor and be checked there.

Treat integrations as alternate inputs

Slack, MCP, Telegram, Linear, and incident.io should not be alternate authority systems. They provide inputs or surfaces. Perelan should still decide whether the action or data read is allowed.

Isolate generated artifacts

Generated dashboards are code-like. They need sandboxing and sharing checks so a useful artifact cannot access cookies, the surrounding app, or data the viewer should not see.

Redact logs and control tokens

Audit records are useful only if they do not become a second sensitive database. Tokens, secrets, PINs, compensation values, candidate PII, and private review payloads need careful redaction.

Say exactly what is certified

Do not invent certification badges, uptime numbers, hosting regions, or subprocessors. If documentation is not public, say so and provide a security-review path.