Trust · Security

Enterprise Security

Security by Design. Trust by Engineering.

Security is not a feature. It is a discipline. At SERGENTA AI, security is foundational to everything we build — from the first architectural decision to the daily operation of enterprise AI systems that our customers depend on.

As the Enterprise AI Division of SERGENTA Group AG, we serve organisations across industries and geographies. These organisations entrust us with their data, their processes and, ultimately, their trust. We take that responsibility seriously.

Our security philosophy is rooted in Swiss engineering values: precision, reliability and an uncompromising focus on quality. We do not pursue security as a compliance exercise or a marketing claim. We pursue it as an engineering principle.

Enterprise security matters because the stakes are real. A security failure can expose sensitive data, disrupt operations, damage reputations and erode the trust that takes years to build. For organisations adopting AI, the stakes are even higher.

This page documents our security practices in detail. It is written for CISOs, compliance officers, IT leaders, procurement teams and anyone responsible for the security of their organisation.

We are working towards internationally recognised security standards such as ISO 27001 and SOC 2 as part of our long-term security and governance roadmap. Where we mention these frameworks, we are describing our objectives — not certifications we currently hold.

Section 01

Our Security Philosophy

Security is not a feature added at the end of development. It is a discipline that begins before the first line of code is written and continues throughout the entire lifecycle of every system we build.

At SERGENTA AI, we treat security as a fundamental engineering responsibility. Every engineer, every architect and every decision-maker shares ownership of the security posture of our platform.

Our approach is grounded in the principle that security must be designed into systems from the outset, not bolted on after the fact.

Security Is Everyone's Responsibility

In many organisations, security is siloed within a dedicated team. We reject this model. Security is a property of the entire engineering culture, not a gate at the end of a pipeline.

This does not mean we do not have security specialists. We do. But their role is to enable, guide and review — not to be the sole owners of security.

Defence in Depth

No single security control is sufficient on its own. We design our systems with multiple layers of defence, so that if one layer fails, others remain to limit the impact of a breach.

Defence in Depth in Practice

Our layered approach includes network segmentation, identity-based access controls, application-level validation, encryption at rest and in transit, comprehensive logging and continuous monitoring.

Long-Term Thinking

Security is not a project with a completion date. It is an ongoing practice that evolves as threats evolve, as systems grow and as our understanding deepens.

We prioritise durability over expediency. We choose transparency over secrecy. And we recognise that building trust takes years while losing it takes moments.

Trust Through Transparency

We believe that customers have a right to understand how their data is protected. We document our security practices openly and acknowledge where we are still growing.

Swiss Engineering Values

As a company rooted in Swiss engineering tradition, we bring a culture of precision, reliability and quality to everything we build.

Section 02

Security by Design

Security by Design means that security is an explicit, considered input into every architectural decision — not a reactive measure applied after problems are discovered.

Before a single component is built, we consider the threats it will face, the data it will process, the access it will require and the failure modes it must handle.

Secure Architecture

Secure architecture begins with understanding the system as a whole — its components, its data flows, its trust boundaries and its dependencies.

Minimal Attack Surface

We expose only the interfaces, ports and endpoints that are strictly necessary. Everything else is restricted by default.

Separation of Concerns

Components are isolated by responsibility. A compromise in one component should not grant access to unrelated systems.

Well-Defined Trust Boundaries

Every interaction between components or systems crosses a documented trust boundary with explicit validation.

Dependency Awareness

We track and evaluate all third-party dependencies, understanding that our security is only as strong as our supply chain.

Threat Modelling

Threat modelling is the structured process of identifying potential adversaries, their motivations, their capabilities and the attack vectors they might use against our systems.

Privacy by Design

We consider the privacy implications of every system from the outset — what data we collect, why we collect it, how long we retain it, who can access it and how it is protected.

Secure Defaults

Systems should be secure out of the box. We design our systems with secure defaults — authentication is required, encryption is enabled, least-privilege access is the starting point.

Zero Trust Principles

We apply Zero Trust principles across our infrastructure. The core idea: never trust, always verify. No request is trusted by virtue of its origin.

This approach significantly reduces the blast radius of a potential compromise. Even if an attacker gains access to one component, they cannot move laterally without re-authenticating.

Least Privilege

Every identity in our system receives only the minimum permissions required to perform its function. Access is granted on a need-to-know basis and is regularly reviewed.

Access is scoped to specific resources and actions, not broad wildcard permissions
Temporary access is time-limited and automatically expires
Privileged access requires additional authentication and is logged
Access reviews are conducted regularly to identify and revoke unnecessary permissions
Service accounts are scoped to specific functions and rotated periodically

Section 03

Secure Software Development Lifecycle

Our Secure Software Development Lifecycle (SSDLC) integrates security into every stage of development — from initial planning through to continuous post-deployment improvement.

A Secure SDLC is not a separate process that runs alongside development. It is the development process itself, enhanced with security activities at each stage.

The following illustrates the ten stages of our SSDLC. Each stage has defined security activities, responsibilities and exit criteria.

Planning

Security requirements are defined alongside functional requirements. Threat models are initiated.

Architecture

System designs are reviewed for security implications. Trust boundaries and data flows are documented.

Threat Modelling

Structured sessions identify potential attack vectors, adversary motivations and applicable controls.

Development

Secure coding standards are applied. Pre-approved libraries and input validation guidelines are followed.

Code Review

All code changes are reviewed by peers. Security-sensitive changes receive additional review.

Testing

Automated tests include security test cases. Unit tests verify input validation and authorisation checks.

Security Validation

Static analysis, dependency scanning and secret detection run automatically on every change.

Deployment

Deployments are automated, repeatable and auditable. Infrastructure is provisioned through code.

Monitoring

Deployed systems are continuously monitored for security-relevant events. Anomalies trigger alerts.

Continuous Improvement

Post-deployment reviews, incident learnings and threat intelligence feed back into the process.

Planning

Security begins before code is written. During planning, we define security requirements alongside functional requirements.

Architecture and Threat Modelling

During the architecture phase, system designs are documented and reviewed. Data flows are mapped, trust boundaries are identified and threat modelling sessions are conducted.

Why Threat Modelling Matters

Threat modelling shifts security left — identifying design-level vulnerabilities before they are encoded. A design-level flaw discovered during threat modelling can be fixed with a diagram.

Development and Code Review

During development, engineers follow secure coding standards. Input is validated at trust boundaries. Secrets are never hardcoded. All code changes undergo peer review.

Security Validation

Before code reaches production, it passes through automated security validation. Static analysis, dependency scanning and secret detection run automatically.

Deployment and Monitoring

Deployments are fully automated. Infrastructure is defined as code, ensuring consistency and auditability. Once deployed, systems are continuously monitored.

Continuous Improvement

The SSDLC is not static. We learn from every deployment, every incident and every threat intelligence update. Security is a cycle, not a line.

Section 04

Application Security

Application security encompasses the controls and practices that protect our software from unauthorised access, manipulation and exploitation.

Applications are the primary interface between users and our platform. They are also the primary target for adversaries.

Authentication

We support strong authentication mechanisms, including password-based authentication with complexity requirements, multi-factor authentication (MFA) and OAuth-based single sign-on.

Authorisation and RBAC

We implement role-based access control (RBAC), where permissions are assigned to roles and roles are assigned to users.

Role-Based Access Control

Permissions are grouped into roles. Users receive roles appropriate to their function, not individual permissions.

Principle of Least Privilege

Each role is scoped to the minimum permissions required. Administrative roles are separate from operational roles.

Resource-Level Authorisation

Every request is checked not only for the action but also for the specific resource being accessed.

Deny by Default

If a permission is not explicitly granted, it is denied. There are no implicit permissions.

Multi-Factor Authentication

Passwords alone are insufficient. We support multi-factor authentication, requiring users to provide additional verification beyond their password. MFA is required for administrative access.

Session Management

Session tokens are generated using cryptographically secure random number generators, are bound to the authenticated identity and have finite lifetimes.

API Security

Every API endpoint requires authentication and authorisation. Input is validated against strict schemas. Rate limiting prevents abuse.

Input Validation and Output Encoding

All input from users, external systems or untrusted sources is validated at the point of entry. Input that fails validation is rejected — never passed through with attempted sanitisation.

All output is contextually encoded before being rendered. This prevents cross-site scripting (XSS) and injection attacks by ensuring that data is treated as data, not as executable code.

Secure Error Handling

Internal error details — stack traces, database schemas, file paths — are never exposed to end users. Users receive generic error messages with unique correlation identifiers.

Dependency Management

We track all dependencies, monitor them for known vulnerabilities and update them promptly when security patches are released.

Software Supply Chain

We verify the integrity of dependencies, use trusted package sources, and maintain reproducible builds where possible.

Secrets Management

Secrets — API keys, passwords, certificates, tokens — are never stored in source code. They are managed through dedicated secrets management systems, rotated periodically and access-controlled.

Logging and Monitoring

Security-relevant events are logged comprehensively. Authentication attempts, authorisation decisions, data access, configuration changes and administrative actions are all recorded.

Section 05

Infrastructure Security

Our infrastructure is designed for resilience, isolation and observability — the three properties that allow us to maintain availability, integrity and confidentiality under real-world conditions.

Even the most carefully designed application cannot be secure if the infrastructure it runs on is vulnerable.

Cloud Infrastructure

Our platform runs on cloud infrastructure that provides built-in security capabilities, including network isolation, encryption services, identity management and logging.

Network Security

We use firewalls, security groups and network segmentation to enforce the principle of least privilege at the network level.

Network Segmentation

Systems are grouped into isolated network zones. Communication between zones is restricted and explicitly allowed only where necessary.

Private Networking

Internal services communicate over private networks. Sensitive databases and internal APIs are never directly exposed to the public internet.

Firewall Rules

Firewall and security group rules follow deny-by-default policies. Only explicitly required traffic is permitted.

DDoS Protection

We leverage cloud-level DDoS protection and rate limiting to absorb and mitigate denial-of-service attempts.

Infrastructure Hardening

All infrastructure components are hardened before deployment — removing unnecessary software, disabling unused ports, applying security patches and enforcing secure configurations.

Backups and Data Integrity

Data is backed up regularly using automated processes. Backups are encrypted, stored in separate locations and tested periodically.

Business Continuity and Disaster Recovery

Redundancy is built into every layer: multiple availability zones, replicated data stores, failover-capable services and geographically distributed infrastructure.

High Availability Architecture

If a server fails, traffic is routed to healthy instances. If a database node fails, replicas take over. If an entire availability zone becomes unavailable, services continue from other zones.

Our disaster recovery plans define recovery point objectives (RPO) and recovery time objectives (RTO) for critical systems. These are tested through periodic recovery exercises.

Infrastructure Monitoring

Infrastructure is continuously monitored for performance, availability and security. Metrics, logs and traces are collected and aggregated into centralised observability platforms.

Resilience and Operational Reliability

A system that is not reliable is not secure. We invest in operational reliability as a security measure, including capacity planning, graceful degradation and circuit breakers.

Section 06

Identity & Access Management

Identity is the new perimeter. In a Zero Trust architecture, every request is authenticated and authorised — regardless of where it originates.

Identity and Access Management (IAM) governs who can access our systems, what they can do once authenticated, and how that access is managed over time.

Identity

Every entity that interacts with our systems — whether a human user, a service account or an automated process — has a unique identity.

Authentication

We support password-based authentication with strong complexity requirements, multi-factor authentication (MFA) and federated authentication through OAuth-based single sign-on.

Authorisation

We implement role-based access control (RBAC), where permissions are assigned to roles and roles are assigned to identities.

Every request is authenticated — no anonymous access to protected resources
Every action is authorised against the caller's role and permissions
Resource-level checks ensure users can only access resources they are permitted to access
Administrative actions require elevated roles and additional verification
All authentication and authorisation events are logged for audit purposes

Least Privilege

Every identity should have only the minimum permissions required to perform its function — and no more.

User Lifecycle Management

Access is managed throughout the user lifecycle — from provisioning through modification to deprovisioning. When a user leaves, their access is revoked promptly.

Access Reviews

Access rights are reviewed periodically to ensure they remain appropriate. Findings are remediated through formal change processes.

Enterprise Identity

For enterprise customers, we support federated identity through standards-based protocols. This allows organisations to manage their users' identities through their own identity providers.

Secure Sessions

Users receive secure session tokens that are short-lived, rotated regularly and bound to the authenticated identity. Idle sessions expire automatically.

Section 07

Data Protection

Data protection is the convergence of security and privacy — ensuring that data is confidential, intact and available only to those who are authorised to access it.

Data is one of the most valuable assets our customers entrust to us. Protecting it is not just a technical requirement — it is a fundamental obligation.

Privacy by Design

We apply the principles of data minimisation, purpose limitation and storage limitation throughout our design process.

Encryption at Rest

Data stored in our systems is encrypted at rest. Even if physical storage media were accessed by an unauthorised party, the data would remain unreadable without the decryption keys.

Encryption in Transit

All data transmitted between users, services and systems is encrypted in transit using Transport Layer Security (TLS).

Key Management

We use dedicated key management systems to generate, store, rotate and revoke encryption keys. Keys are access-controlled, audited and never exposed in source code.

Data Integrity

We use cryptographic hashes, checksums and authenticated data structures to detect unauthorised modifications.

Backups

Data is backed up regularly to protect against loss. Backups are encrypted, stored in separate locations and tested periodically.

Secure Deletion

When data is no longer needed, it is securely deleted. This applies to production data, backups, logs and cached copies.

Data Minimisation and Classification

We classify data based on its sensitivity and apply appropriate controls based on classification.

Data Minimisation

We collect only the data necessary for the stated purpose. Unnecessary data is not collected.

Data Classification

Data is classified by sensitivity. Each classification level has defined handling requirements and access controls.

Purpose Limitation

Data collected for one purpose is not repurposed for unrelated uses without appropriate authorisation.

Storage Limitation

Data is retained only as long as necessary, then securely deleted in accordance with retention policies.

Security and Privacy: Working Together

Security provides the technical controls that make privacy possible. Privacy provides the principles that guide how security controls are applied.

Section 08

AI Security

Enterprise AI introduces an entirely new category of security challenges. Traditional security controls are necessary but no longer sufficient.

As an Enterprise AI company, we recognise that AI systems introduce unique security risks. Large language models can be manipulated through carefully crafted inputs. Training data can contain sensitive information.

LLM Security

Adversaries may attempt to extract sensitive information from model outputs, manipulate model behaviour through crafted prompts, or use models to generate harmful content.

Prompt Injection

Prompt injection is a class of attack where an adversary attempts to override the instructions given to an AI model. We mitigate this through input validation, output filtering and least-privilege access for AI agents.

How We Mitigate Prompt Injection

AI agents operate with constrained permissions — they can only access data and perform actions explicitly granted to them. Even if an agent is manipulated, the blast radius is limited.

Data Isolation

Customer data is not used to train shared models. AI agents access only the data they are explicitly authorised to access. Conversation contexts are isolated between users and organisations.

Model Governance

We maintain awareness of the models we use, their capabilities, their limitations and their known risks. Model changes are reviewed and tested before deployment.

Secure AI Workflows

Each step in a workflow operates with least privilege. Data passed between steps is validated. Sensitive operations require human approval. Audit trails capture what each step did.

Human Oversight

AI systems at SERGENTA AI are designed to augment human decision-making, not replace it entirely. Critical actions require human review and approval.

This human-in-the-loop approach ensures that AI operates as a tool within human-controlled boundaries.

Auditability

We log AI agent activities — what they were asked to do, what data they accessed, what tools they invoked and what outputs they produced.

Responsible AI

We are committed to developing AI systems that are not only secure but also fair, transparent and accountable.

Enterprise AI Controls

Enterprise customers need to know where their data goes, who can access it, how it is used by AI systems and how to control it. We provide visibility into AI data flows and configurable access policies.

Future AI Governance

AI security is a rapidly evolving field. We are committed to staying informed, adapting our practices and contributing to the broader conversation about secure and responsible AI.

Section 09

Monitoring & Incident Response

Detection is the first step in response. Comprehensive monitoring, combined with a structured incident response process, allows us to identify, contain and remediate security events quickly.

No security control is perfect. The question is not whether an incident will occur, but when — and how quickly we can detect, respond and recover.

Logging

Security-relevant events are logged comprehensively. Logs are centralised, structured and tamper-resistant.

Monitoring and Alerting

We use automated monitoring systems that analyse logs and metrics in real time, generating alerts when suspicious patterns are detected.

Operational Visibility

Performance metrics, error rates, traffic patterns and resource utilisation are all monitored. Anomalies can indicate security issues.

Incident Management

When a security incident is detected, it enters a structured incident management process with clear roles, responsibilities and communication protocols.

Detection

An incident is identified through monitoring, alerting, user reports or external notifications.

Triage

The incident is assessed for severity, scope and potential impact. An incident lead is designated.

Containment

Immediate actions limit the spread — isolating affected systems, revoking access, blocking traffic.

Investigation

The root cause is identified through log analysis, forensic examination and systematic investigation.

Remediation

The vulnerability is fixed. Affected systems are restored to a known-good state.

Communication

Affected parties are notified with relevant, timely information about the incident and its resolution.

Post-Incident Review

The incident is reviewed in detail. Lessons learned are documented and fed back into preventive controls.

Root Cause Analysis

Every significant incident undergoes root cause analysis (RCA) to identify the underlying factors that allowed the incident to occur.

Post-Incident Reviews

Post-incident reviews are conducted in a blameless culture — the goal is to understand what happened and why, not to assign blame.

Service Reliability

Security incidents and operational incidents are often intertwined. We treat security and reliability as complementary disciplines.

Section 10

Business Continuity

Business continuity is the ability to maintain critical operations during and after disruptive events — whether caused by natural disasters, infrastructure failures, cyber attacks or human error.

Resilience is a security property. A system that cannot recover from disruption is not secure, regardless of how well it is protected against direct attacks.

Operational Resilience

We achieve operational resilience through redundancy, graceful degradation, circuit breakers and fallback mechanisms.

Disaster Recovery

Our DR plans define recovery point objectives (RPO) and recovery time objectives (RTO) for each critical system.

Recovery Objectives

RPO defines the maximum acceptable data loss, measured in time. RTO defines the maximum acceptable downtime before systems must be restored. These are tested through periodic recovery exercises.

Backup Strategies

We implement automated, encrypted, and geographically distributed backups for all critical data. Backups are tested regularly.

Infrastructure Redundancy

Single points of failure are eliminated. Our infrastructure uses multiple availability zones, replicated data stores and load-balanced services.

Business Continuity Planning

Business continuity planning addresses the operational, communicative and organisational aspects of disruption response.

Future Scalability

We continuously evaluate our resilience posture, invest in additional redundancy and refine our recovery procedures.

Section 11

Security Culture

Tools and processes are necessary but not sufficient. The strongest security control is a culture where every team member understands their role in protecting our customers.

Security culture is created by the everyday actions of every team member, reinforced by leadership and embedded in the way work is done.

Security Awareness

Every team member receives security awareness guidance appropriate to their role. Awareness is an ongoing conversation, not a one-time training.

Engineering Culture

Security is part of the craft of engineering. Developers write secure code. Architects design secure systems. Reviewers catch security issues.

Responsible Behaviour

We encourage and reward responsible behaviour — including the willingness to say 'this doesn't look right' without fear of negative consequences.

Continuous Learning

The security landscape changes constantly. We invest in continuous learning — sharing knowledge across the team and regularly reviewing our practices.

Internal Reviews

We conduct internal security reviews — not just of code, but of processes, configurations and access patterns.

Shared Responsibility

Security is everyone's job. When every team member understands that they are part of the security programme, the organisation becomes significantly harder to attack.

Section 12

Responsible Disclosure

We welcome and value reports from security researchers. If you believe you have identified a security vulnerability, we encourage you to report it to us responsibly.

We are committed to working collaboratively with researchers who report vulnerabilities in good faith.

How to Report

Please report vulnerabilities with as much detail as possible — description, reproduction steps, potential impact and remediation suggestions. Please do not publicly disclose until we have had an opportunity to investigate.

Report a Vulnerability

Please send vulnerability reports to our security team. Include detailed reproduction steps, impact assessment and any relevant technical details. We acknowledge all reports.

Our Process

Acknowledgement

We acknowledge receipt of your report and assign a tracking identifier.

Investigation

Our security team investigates the report, attempting to reproduce the vulnerability and assessing its scope.

Validation

If confirmed, we assess severity and prioritise remediation accordingly.

Remediation

We develop and deploy a fix. The timeline depends on severity and complexity.

Communication

We keep the reporter informed throughout and coordinate on public disclosure after remediation.

Guidelines for Researchers

Report vulnerabilities in good faith with the intent of improving security
Provide sufficient detail to allow us to reproduce and validate the issue
Avoid accessing, modifying or destroying data that does not belong to you
Do not perform actions that could degrade service availability for other users
Do not publicly disclose the vulnerability until we have remediated it
Respect the privacy of other users and our team members

Future Bug Bounty Programme

We plan to establish a formal bug bounty programme in the future to provide structured recognition for security researchers.

Section 13

Security Roadmap

Security is a journey, not a destination. This page documents not only where we are today, but where we are headed.

We believe in transparency about our security maturity. We do not claim to have achieved everything we aspire to.

Current Focus

Our current focus is on building strong foundational practices — secure development, infrastructure hardening, access management, monitoring and incident response.

Growing Organisation

As we add team members, customers and capabilities, we continuously evaluate and strengthen our security posture.

International Standards

We intend to work towards frameworks such as ISO 27001 and SOC 2 as the organisation continues to grow and mature.

An Honest Statement

We have not yet achieved ISO 27001 or SOC 2 certification. These are objectives we are working towards, not credentials we currently hold. Any mention of these frameworks refers to our roadmap and intentions.

Continuous Improvement

Regardless of certifications, our commitment to continuous improvement is unwavering. Security is never 'done' — it is always evolving.

Enterprise Readiness

Our security programme is designed to meet the expectations of enterprise customers — CISOs, compliance officers, procurement teams and IT departments.

Frequently Asked Questions

Common questions about our security practices, policies and roadmap.

How does SERGENTA AI approach security?

Security is integrated into every stage of our engineering process. We follow a Security by Design philosophy, applying defence in depth, least privilege and Zero Trust principles.

How do you protect customer information?

Customer data is protected through encryption at rest and in transit, strict access controls, network segmentation, comprehensive logging and continuous monitoring.

What security principles guide development?

Our development is guided by secure coding standards, threat modelling, peer code review, automated security testing and a Secure Software Development Lifecycle.

Do you use secure coding practices?

Yes. All code follows secure coding standards including input validation, output encoding, secure error handling, secrets management and dependency management.

Do you plan to obtain ISO 27001 certification?

We intend to work towards ISO 27001 certification as part of our long-term security roadmap. We have not yet achieved this certification.

Are you SOC 2 certified?

Not at this time. SOC 2 is part of our long-term governance roadmap. We have not yet undergone a formal audit.

How do you secure AI systems?

AI security includes prompt injection mitigation, strict data isolation, least-privilege access for AI agents, human oversight, comprehensive audit logging and model governance.

How can vulnerabilities be reported?

We welcome responsible disclosure reports. Reports can be sent to our security team with detailed reproduction steps and impact assessment.

Do you have a bug bounty programme?

Not yet. We plan to establish a formal bug bounty programme in the future. In the meantime, we deeply appreciate responsible disclosure reports.

How do you monitor infrastructure?

Our infrastructure is continuously monitored using centralised logging, real-time alerting and operational visibility tools.

How do you manage access control?

We implement role-based access control (RBAC) with least-privilege principles. Administrative access requires multi-factor authentication.

What is Security by Design?

Security by Design means security is an explicit consideration in every architectural and development decision — not a reactive measure.

Is data encrypted?

Yes. Data is encrypted at rest using industry-standard encryption, and all data in transit is protected using TLS.

How do you handle incidents?

We follow a structured incident response process: detection, triage, containment, investigation, remediation, communication and post-incident review.

Do you support multi-factor authentication?

Yes. MFA is available to all users and is required for administrative access. We also support federated authentication through OAuth-based SSO.

How do you handle backups?

Data is backed up regularly using automated, encrypted processes. Backups are stored in separate locations and tested periodically.

What is your approach to data privacy?

We apply Privacy by Design principles: data minimisation, purpose limitation and storage limitation.

Do you train your team on security?

Yes. Every team member receives security awareness guidance appropriate to their role.

How do you secure third-party dependencies?

We track all dependencies, monitor them for known vulnerabilities and update them promptly when security patches are released.

What is your disaster recovery plan?

Our DR plans define RPO and RTO for critical systems. We achieve resilience through infrastructure redundancy, automated backups and periodic recovery testing.

Related Resources

Explore further

Compliance Privacy Responsible AI AI Governance Engineering Standards Documentation Platform Architecture Contact Security Team