Security and Governance

Role-based access, two-factor sign-in, encrypted credentials, a tamper-evident audit trail and version history, framed for due diligence.

Built to pass the due-diligence checklist

An integration platform touches every important system an organisation runs, so it is usually the first thing a security review examines. This page answers the questions such a review asks. The short version: access is role-based and layered, credentials are encrypted, every material action is recorded in a tamper-evident trail, configuration is versioned with restore, and traffic is encrypted throughout. The full position is published at /trust.

Who can do what

Console access uses ranked roles, from read-only viewing through operating jobs and reports, designing integrations, and full administration. Sensitive areas, including user management, the audit trail and configuration history, are reserved for administrators, and each person holds the least role their work requires. At Demo ISP, the operations team runs reports and schedules daily, while only two named people can change a mapping.

Portals carry an entirely separate permission system. Each portal defines its own roles and users, granted access page by page and resource by resource, down to hidden columns and row-level rules such as "only your own records". Those rules are enforced by the server, so data outside a user's grant is unreachable rather than merely hidden from view. Portal users never gain any console access.

Proving who is signing in

Two-factor authentication with a standard authenticator app is available for the console, and the requirement can be set per role, so administrators can be compelled to enrol while lighter roles are not. Portals support single sign-on through your organisation's identity provider, so customer and staff sign-ins follow the policies you already run. Machine-to-machine callers authenticate with scoped keys limited to the routes they need.

Secrets stay secret

Connection credentials for source systems live in an encrypted vault. The console records that a credential exists and where it is used, and never displays the secret itself. Configuration exported for backup or promotion carries no live secrets. Rotating a password is one change in one place, with every connection that uses it following automatically.

An audit trail you can rely on

Material actions are recorded: who signed in, who changed a mapping, who approved an AI proposal, who viewed sensitive data, when, and from where. The trail is tamper-evident, so entries cannot be silently altered or removed after the fact, which is the property auditors ask about first. When a regulator or a customer asks what happened to a record, the answer is a report rather than an investigation.

Nothing is lost, everything can go back

Configuration changes are kept as version history. Queries, reports, workflows and portals are edited as staging copies and pushed to production deliberately, and any pushed version can be restored. A change that misbehaves on Tuesday is rolled back to Monday's version in one step. The same history shows what changed between any two points in time, which turns "what changed last week?" from a memory exercise into a lookup.

Encrypted in transit

Console, portal and API traffic runs over TLS, and connections to source systems use each system's encrypted transport where it offers one. STRAX also installs fully on your own infrastructure, so data can remain inside your network boundary end to end.

Where this fits

Security is a property of the whole platform described in What is STRAX?, from connecting systems through portals. For a formal review, start at /trust or request a quote and ask for the due-diligence pack.