Security Posture

These are the principles Endeavor Engineering designs and operates against. They apply to everything we build and run — our own infrastructure, the connectors that run in your environment, and the VirtualForge cloud platform.

They are stated as principles rather than as a control matrix on purpose. A control list tells you what a system does today; a principle tells you what we will do when we meet a case the list did not anticipate.

Identity is the perimeter

Trusting traffic because it arrived from the right network is not sufficient for distributed or cloud systems. We treat identity as the primary security boundary.

• Every actor — person, service, or plugin — has a distinct, verified identity.
• Authentication is required at every system boundary, regardless of network origin.
• Access is granted to identities, never to network addresses.
• Machine and service identity uses short-lived, federated credentials. We do not issue long-lived access keys and we do not use shared service accounts.

Least privilege

Every identity gets the minimum permission its stated function requires — nothing more. Permissions are not granted speculatively or "just in case", and privilege escalation is explicit and logged.

Multi-factor authentication

MFA is the standard for interactive access to administrative and production systems, and for cloud management consoles. Password-only authentication is not acceptable for privileged access.

Defence in depth

No single control is relied on exclusively. Network, identity, application, data, and detection controls are layered so that a failure in one does not become a complete compromise.

Secure by default

Systems are deployed in their most secure configuration, and the insecure option is the one that needs a documented justification.

• No default credentials — defaults are changed at provisioning.
• Services are not exposed publicly without a specific reason.
• Encryption is on by default; plaintext is the exception.
• Logging is on by default; disabling it requires justification.

Data protection

• In transit: TLS 1.2 or better for all external connections and for service-to-service traffic. No plaintext channels for sensitive data.
• At rest: sensitive data encrypted with strong, modern ciphers.
• Keys: managed in a dedicated secrets and key-management service, never hardcoded and never committed to a repository.

Specifics of how this applies to your operational data — including what is isolated per customer and what is shared — are on Data handling and isolation.

Auditability

Security-relevant events are logged: authentication outcomes, authorization decisions on sensitive operations, administrative actions with actor identity and timestamp, and configuration changes.

Our standard for those logs is that they are centralized rather than left only on the system that produced them, written so the system being logged cannot alter them, and retained against compliance requirements. Cloud management activity already meets it, through a consolidated and validated audit trail that makes privileged actions attributable. Centralized application-level logging is built but not yet complete — infrastructure monitoring is operating, the application tier is being brought onto the same footing. We would rather tell you which half is done.

Change control

Changes — especially security-relevant ones — are recorded before and after, tracked in version control, reviewed before reaching production, and exercised in a non-production environment first.

Architectural decisions are captured as written records that state the alternatives rejected and the conditions under which the decision should be revisited. That corpus is internal, but it is the reason we can answer "why is it built this way?" years after the fact — and it is directly usable as change-management evidence.

Use of AI in engineering

We use AI assistance heavily, and the limits are firm: no customer data, no production credentials, context reviewed before it is shared, and an engineer reviewing anything AI-assisted before it ships. AI is not an autonomous actor in our release path.

That deserves more than three bullets, so it has its own page — AI in our engineering.

Vendors and cloud providers

Third-party systems are held to the same standards we hold ourselves to. Vendor access is scoped to the minimum required, cloud resources are configured to our standards rather than left at provider defaults, provider access logs are enabled and retained, and integrations use dedicated scoped credentials rather than administrative ones.

Where a vendor processes customer data on our behalf, we maintain a subprocessor list and the corresponding agreements. Ask us for the current list — see Compliance posture.

When these principles are applied

At architecture design, in code review, and in compliance review. A new system is assessed against these principles before it is built, rather than audited against them afterwards.