Security Practices
Six areas of security practice applied consistently across every Ascii-Core project — from the first line of code to ongoing production monitoring. Built for clients who operate in regulated industries and international markets.
Code Security
Every codebase we ship starts with a security-conscious foundation: strict TypeScript, automated dependency scanning, input validation at API boundaries and zero secrets in version control. These are not add-ons — they are project initialisation standards. We run the OWASP Top 10 checklist as a deployment exit criterion, not as an audit afterthought.
- TypeScript strict mode on all projects — type safety eliminates entire classes of injection and runtime errors.
- Dependency scanning via Dependabot — automated pull requests for known CVEs in npm and Python packages.
- OWASP Top 10 checklist reviewed before every production deployment.
- No secrets in source code — environment variables via .env files, never committed; production secrets via secrets manager.
- Input validation on every API endpoint using Zod or equivalent schema validation library.
- Output sanitisation before any user-facing rendering to prevent XSS.
Infrastructure Security
Infrastructure security is configured at provisioning time, not retrofitted after a security review. Databases are never exposed to the public internet. Service accounts operate with least-privilege IAM policies. Secrets are stored in a dedicated secrets manager, not in environment files on disk. This baseline is consistent across all client deployments regardless of project size.
- Environment variable management via secrets manager (AWS Secrets Manager, Doppler or Vercel Environment Variables) — no plaintext secrets in environment files on production servers.
- Least-privilege IAM policies — service accounts have only the permissions they require, reviewed quarterly.
- VPC configuration for database and internal service isolation — database ports never exposed to the public internet.
- Automated security updates for operating system packages on managed infrastructure.
- SSH key-based access only — password authentication disabled on all servers.
- Network egress filtering on production environments handling sensitive data.
Data Security
Data is encrypted at rest and in transit on every project. For clients with data residency requirements under GDPR (EU data) or CNDP (Moroccan data), we deploy within the required geographic region and document the data processing architecture for compliance review. We do not log sensitive payloads to third-party monitoring services without explicit client approval and appropriate data processing agreements.
- Encryption at rest — all databases use AES-256 encryption at the storage layer (enabled by default on managed providers; explicitly configured on self-hosted deployments).
- Encryption in transit — TLS 1.3 enforced on all API endpoints, webhooks and internal service communication.
- Data residency options — for Morocco-based clients and EU clients with data localisation requirements, we deploy within specified geographic regions.
- No third-party logging of sensitive data — API response payloads containing PII are excluded from request logging.
- Data retention policies implemented in the database schema — records with defined lifecycles are purged on schedule.
- Backup encryption — automated backups are encrypted before leaving the production environment.
Authentication & Access Control
Authentication is the most common attack vector on web applications. We implement short-lived JWT access tokens with refresh token rotation so that a stolen token expires quickly. OAuth 2.0 for social login means we never store passwords for those flows. MFA is required for administrative access on all production systems. RBAC is designed during the Architecture phase and validated during QA — it is not added after the fact.
- JWT access tokens with short expiry (15 minutes) paired with refresh token rotation — stolen access tokens have a limited blast radius.
- OAuth 2.0 / OIDC for third-party authentication (Google, Microsoft, GitHub) — no password storage for social login flows.
- MFA support on all admin and privileged accounts — enforced, not optional, for production system access.
- Role-based access control (RBAC) — permissions are granted by role, not by user, and reviewed during the QA phase.
- Session invalidation on logout — refresh tokens are revoked server-side, not just deleted client-side.
- Rate limiting on authentication endpoints — brute-force protection via Redis-backed request counting.
AI-Specific Security
AI systems introduce attack vectors that do not exist in traditional software: prompt injection, jailbreaks, data exfiltration via LLM context and cost attacks via generation volume. We address these explicitly in the architecture phase. User inputs are never concatenated directly into system prompts. PII is masked before external API calls. Every agent action is logged. Output is validated before it triggers any downstream effect. These are engineering controls, not policy statements.
- Prompt injection prevention — user inputs are separated from system prompts and never concatenated directly into instruction context.
- Output sanitisation — LLM responses are parsed and validated before being displayed, stored or used to trigger actions.
- PII filtering in LLM pipelines — personally identifiable information is masked or replaced before being sent to external LLM APIs.
- Audit logging for AI actions — every tool call made by an AI agent is logged with timestamp, input, output and user context.
- Rate limiting on AI endpoints — per-user and per-organisation limits prevent cost abuse and denial-of-service via generation.
- LLM output guardrails — content policy checks run on outputs before they reach the user or trigger downstream actions.
Compliance
Compliance is a shared responsibility. Our engineering controls provide the technical foundation — encryption, access control, audit logging, data retention — but formal compliance certification requires organisational processes beyond the engineering team. We are transparent about this boundary. We implement SOC 2-aligned controls and produce the documentation that a compliance audit requires; formal certification is arranged with a specialist audit firm if clients require it.
- GDPR data processing agreements — we sign DPAs with clients processing EU personal data and document the data processing architecture.
- CNDP (Morocco) awareness — Moroccan clients are advised on data processing notification requirements under Law 09-08.
- SOC 2-aligned practices — our security controls align with SOC 2 Type II criteria; formal certification is available on request via a specialist audit firm.
- Data flow documentation — we produce a data flow diagram for every system showing where personal data is stored, processed and transferred.
- Third-party sub-processor documentation — we maintain a list of sub-processors (LLM APIs, hosting providers, monitoring tools) shared with clients on request.
- Right-to-erasure support — database schemas are designed to support GDPR Article 17 erasure requests without full database reconstruction.
What we do not do
We are transparent about the boundary between our engineering work and specialist security services.
- We are not a penetration testing firm. We do not conduct formal penetration tests or produce CREST-certified pentest reports. We recommend specialist firms for this work and provide them with access to the environment and architecture documentation.
- We do not offer compliance certification. Formal ISO 27001, SOC 2 Type II or PCI-DSS certification requires an accredited auditor. We implement controls aligned with these standards and produce supporting documentation, but we are not the certifying body.
- We do not conduct formal legal advice on GDPR or CNDP compliance. We provide technical data processing documentation; legal interpretation of regulatory requirements requires a qualified data protection lawyer.
Security questions answered
Common questions about security reviews, data residency, NDAs and AI agent access controls.
Need to discuss security requirements under NDA?
We sign mutual NDAs before technical discussions. Contact us and we will send our standard NDA for review before any detailed conversation about your security requirements or existing infrastructure.
Building something that requires enterprise security?
Every Ascii-Core project ships with the security foundations described here as standard. Let us discuss your specific requirements.