Security & Governance

Afunana reads the legacy source that runs the business, often an institution's most sensitive asset.Security is a design constraint, not a bolt-on.The platform runs inside the customer's own network.Nothing about the analyzed systems leaves that boundary unless the customer configures an outbound integration.That means an LLM provider, a SIEM, or the source system.Compliance & Standards maps these controls to OWASP, ISO/IEC 27001, and SOC 2.

Signing in, and what each person can see

Two questions are answered separately on every request.What this person is allowed to do, and which systems they are allowed to see it for.Both have to pass.Sessions expire and can be revoked.People can sign in through the organisation's own identity provider.AI tools and scripts go through the same checks as the browser.

Authentication

Sessions are carried by HS256-signed JWTs.The signing key must be at least 256 bits.It is a bootstrap secret from a mounted container secret or the environment, never the database.The process refuses to boot if it is unset or too short.

Passwords are hashed with bcrypt (per-password salt) with enforced complexity.They are never logged or stored in plaintext.Reset tokens are kept only as SHA-256 hashes with a short expiry.Against enumeration, the forgot-password flow returns a generic response whether or not the address exists.Login equalizes response timing for unknown-user and wrong-password outcomes.Repeated failed logins lock the account.That lockout is persisted, survives a restart, is audited, and guards the SSO callback path.

Session management

Two independent clocks bound every session.An idle timeout expires a token after a configurable period of inactivity.An absolute lifetime (configurable, shipped at 8 hours) is enforced on every refresh and cannot be extended.Revocation is per-token on logout, checked on every authenticated request.It is per-user by an administrator, who can also force every user to re-authenticate.Both are audited, and logout propagates across browser tabs.

Roles, and the data a role reaches

Authorization answers two independent questions, and both must pass before a request succeeds.

What may this person do? Every user holds one role.A role is a named bundle of permissions.Examples: collection.view, collection.build, collection.delete, source.write.Six roles ship.admin does everything.pgmr defines and builds collections, edits source, administers nobody.qa adds the review screens and the audit log.analyst reads and asks questions.user is the default.viewer is read-only, with no chat, so it spends nothing on the LLM.A single permission can be granted or denied to one person on top of their role.That covers the exception that does not justify a new role.

Which data may they see? Separately, a person is given collections, one at a time or as a whole application.An application reaches every collection filed under it and under anything nested inside it.That includes collections created later.The role decides what kind of operation is allowed; this decides which data it may touch.Neither substitutes for the other.A permission to delete a collection does not say which collections exist for that person.

An application is a named business division of the estate — Life insurance, and inside it Life calculations.Applications nest, and a grant travels downward only.Holding Life holds Life calculations.Holding Life calculations holds nothing above it.

Access can be handed out by the customer's own directory rather than maintained here.A mapping row like "group Claims-IT holds the Claims application" is re-evaluated at every login.It withdraws access as well as granting it.A person who transfers out of a department loses that department's documentation at their next sign-in.Nothing is entered on our side.

The backend is authoritative.Every protected endpoint declares its guard server-side, and requests without it return 403.Frontend route guards are usability only.The permission check fails closed: if the tables cannot be read, the answer is no.Admitting somebody on the strength of a broken query is how an authorization check becomes decorative.An administrator cannot be denied the two permissions that would prevent them from reversing the denial.

Single sign-on

Afunana supports OpenID Connect (OIDC).It is used with Azure AD (Microsoft Entra ID), Okta, Google Workspace and generic providers.ID tokens are validated against the provider's published JWKS keys with issuer, audience and expiry checks.A token whose signature cannot be verified is rejected, with no fall-through to an unverified decode.Discovery is SSRF-guarded.A discovery or JWKS URL must be HTTPS and resolve to a public address, so it cannot point at internal services.Each login mints a random, single-use, time-boxed state parameter and a nonce, defeating CSRF and replay.

Afunana also supports SAML 2.0 as a service provider.Many enterprises federate applications to an internal ADFS or a SAML tenant rather than issuing OIDC registrations.Assertions are verified against the certificate the administrator configured, never one carried inside the response.Everything read afterwards comes from the subtree that signature actually covered.That makes XML Signature Wrapping structurally impossible rather than a check that has to be remembered.Beyond the signature, its issuer, audience, recipient and destination must all name this install.It must be inside its validity window and answer an authentication request this install issued.Its ID must not have been seen before.XML is parsed with entity resolution, DTD loading and network access disabled.A document carrying a DOCTYPE is refused outright.

Both protocols resolve through one identity layer.A person is joined to their provider by its immutable subject rather than by email.Directory group membership can grant roles and collection access as data an administrator edits, not a code change.Auto-provisioning is optional in both, and its default role can never be admin.Either can be restricted to an email-domain allow-list.Every step is audited.

Request defences

For the local (non-SSO) session, CSRF defense uses Origin validation on every mutating request.The Origin is checked against the CORS origins, the frontend URL and the request's Host header.A mismatched or missing Origin is rejected.Rate limiting is per client and returns HTTP 429 when exceeded, strictest on the authentication endpoints.It throttles volume from an address, while lockout stops guessing against an account.

Security headers

The application sets these headers in middleware, not the proxy.They apply even behind a customer's own reverse proxy.

The audit trail

Every security-relevant action is written to a log the database will not let anyone edit or delete.Each record is chained to the one before it, so a change to any historical record can be detected.Nothing is forwarded outside the machine unless an administrator turns it on.

The audit trail

The audit store is INSERT-only and tamper-evident.Each record's integrity hash covers the previous record's hash plus its own identifying fields.That forms a SHA-256 hash chain.Altering or deleting any historical record breaks the chain from that point forward, detectably.Immutability is enforced at the database layer, not just in application code.A trigger blocks any modification or deletion.The only writer that may bypass it is the scheduled retention purge, which does so briefly and under audit.

Events are categorised as authentication, authorization, data access, chat, administration, system and integrity.Each is attributed to an actor, IP address, user agent, target and outcome.Chat query text is logged only when explicitly enabled, off by default for privacy.

Retention is configurable and defaults to 365 days.A scheduled daily purge removes only records past that window.Where SIEM forwarding is enabled it removes only records already confirmed forwarded.Nothing is discarded before it has reached the customer's own retention system.

Events can be forwarded to a customer SIEM in real time, before the local insert.This is possible because the immutability trigger forbids amending a record afterwards.Transports are syslog (RFC 5424) over TLS or an HTTPS webhook; formats are CEF or JSON.A scheduler verifies chain integrity hourly and in full daily, reporting where the chain first breaks.Failures raise a critical event that forwards to the SIEM.

Outbound log streams

Two independent outbound doors exist, and both are OFF by default.Nothing leaves the box unless an operator turns it on.They are configured through different mechanisms on purpose:

• Audit forwarding to a SIEM — the door described above.It is controlled by settings held in the application database, edited on Configuration → Audit & SIEM.Audit events are a database concern.
• Application-log export — ships the application log stream to a collector over the same transports and formats.It is controlled by environment variables, not the database.Application logging must be running before the database is reachable.A bad address is reported and the application still starts; a mistyped collector never blocks an install.

Both doors support TLS and mutual TLS, and multiple destinations.Fields can be redacted or pseudonymized before egress.They share one field set and identity.A receiver can correlate an audit event with the application-log lines from the same request.

Secrets, encryption and hardening

The source code Afunana reads is often the most sensitive asset an organisation holds.It stays inside the organisation's own network.This section covers where credentials come from and what is encrypted in transit and at rest.It also covers how the installation is hardened, what an air-gapped site gives up, and how machines are authenticated.

Secret management

Secret resolution follows two deliberately different precedence chains.Bootstrap secrets are the database connection settings, the token signing key and the server's role designation.They come from a mounted container secret or an environment variable and never from the database.They unlock the database itself, so they cannot depend on it.Startup fails loud if one is missing.

General secrets are API keys, SMTP credentials and SIEM tokens.They resolve through a layered hierarchy.An external secret vault (CyberArk CCP or HashiCorp Vault) comes first when configured.Then a writable on-box layer that allows rotation from the admin UI with no restart.Then mounted container secrets, then database configuration, then the environment.Secrets are never logged, and sensitive values are masked in audit detail.

Encryption

In transit.TLS everywhere.The bundled proxy terminates TLS with automatic certificates and enforces HSTS (max-age=31536000).An external proxy is held to the same standard.Database connections and outbound integrations alike require encrypted transport.

At rest.SQL Server Transparent Data Encryption (TDE), AES-256.In bundled-DB mode TDE is enabled automatically.It encrypts files and backups.In external-DB mode the database is the customer's.TDE, or an equivalent at-rest control, is the customer's responsibility to configure.Afunana cannot enable it for them.This matters for audit evidence.Only bundled-DB deployments can point to Afunana as the party that enabled at-rest encryption.

Platform hardening and vulnerability management

The application runs as an unprivileged service account, never root.The production image excludes build tooling.Data services are reachable only on the internal container network.In bundled mode it uses a least-privilege database login.

Every deploy runs dependency CVE scanning for Python and JavaScript plus static analysis of Python source.Scans are non-fatal: recorded, not blocking.The code-quality check catalog lives in configuration rather than code.Changes to it are governed by the same admin authorization and audit logging as all other configuration.

On-premise and air-gapped operation

Afunana runs inside the customer's perimeter with zero vendor access.In fully air-gapped mode, every LLM call routes to a local model and embeddings come from a local open-source model.The platform installs from an offline image bundle against an internal registry mirror.No data — and no LLM prompt — leaves the box.

AI tools and the API

The Model Context Protocol server, over stateless Streamable HTTP, uses OAuth 2.0 Authorization Code with PKCE.External assistants connect under the same identity model as the web UI.PKCE (S256) is required on every flow and every request is bearer-JWT validated.The implementation follows RFC 8414, RFC 9728 and RFC 7591.

The server is mounted at /mcp (Streamable HTTP transport).A wrapper rejects any request without a valid bearer JWT before the MCP app is reached.Beyond bearer validation, each tool invocation is scoped to the collections carried in the caller's token.Anything outside that list is refused, so an MCP client cannot read another tenant's collection.

Records for AI governance

Afunana provides records about its own use of AI.Your organization can use them when assessing the product and deciding how it should operate.These records do not govern other AI systems in your organization.

Responsibilities and assessments

Record named responsibilities, intended use and assessment results.These are governance records, separate from the permissions granted to user accounts.

Usage and incidents

Review recorded AI usage and estimated costs.Maintain incident and concern records, including severity and actions taken.Estimates depend on configured pricing and the usage recorded.

Reports for internal review

Export governance reports and review the evidence relevant to your installation.A completed record is not proof that a control is enforced.Check the actual deployment and any external evidence before reaching a conclusion.

Evaluation evidence and governance decisions

Evaluation and governance answer two connected questions.What supports an explanation, and who decides how to use it.Current documentation checks, source references and recorded passage reviews provide evidence for that decision.

Each program document carries an evaluation tied to the exact versions of the document and source examined.Checks that use no AI run in every build.They cover the names the document uses, the line ranges it cites and the calls and files in the code.On request, a second model reads each section beside the code and shows the source lines behind it.It follows real values through each business rule.It lists what the code does that the document leaves out.Every quotation is verified against the source, and a disagreement is shown only after a second pass confirms it.The result records the model, prompts, tokens and time.A reviewer's recorded decision keeps what the evaluation said at that moment.

Evaluation of chat answers and specialist-reviewed benchmarks are on the roadmap.They will measure correctness and omissions across changes.Dependency results are not whole-document accuracy scores.

This direction draws on NIST AI RMF, ISO/IEC 42001 and ISO/IEC 23894.They are references for measurement, governance and risk management.

These features support your review process.They are not an independent certification or a regulatory determination.

Standards and regulations

Two sets of rules apply to a product like this.Some govern the software itself, others the use of AI.Both are held the same way.Each requirement is a row carrying two things side by side.The position your own people recorded, and what the running system reports.The two are never merged.Where a requirement is recorded as met but the software reports otherwise, the row is flagged and counted.Either the evidence lives outside the software, or the record is wrong.

For the software itself

• OWASP Top 10 (2021) — application-security risk categories
• ISO/IEC 27001:2022 — Annex A information-security controls
• SOC 2 Type II — AICPA Trust Service Criteria

For the AI

Sector and national rules are carried the same way.Each is its own requirement set, kept beside these rather than folded into them.Ask us what already exists for your regulator.An instrument that is announced but not issued is labelled as announced.Preparing for it is useful; claiming compliance with an unpublished text is not.

What these mappings are, and are not

They state, for each framework item, how Afunana's implemented controls address it.It is an engineering self-assessment that helps security, audit and GRC fit the platform into their own controls.They are not a certification or an attestation.Afunana is mapped to these frameworks, not certified against them.Do not infer an independent certification or examination from these mappings.Request current assurance evidence separately.Read "addresses," "supports," or "mapped to" as an implementation claim to verify against your own deployment.It is never independent assurance.

The complete item-by-item mappings are documented and available on request.They cover OWASP Top 10, ISO/IEC 27001:2022 Annex A, and SOC 2 common criteria, availability and confidentiality.

Two limits are stated plainly rather than mapped away.Local accounts can be required to enter an authenticator code at sign-in (none, admins or all); SSO accounts take MFA from their identity provider.At-rest encryption is automatic only in bundled-DB deployments.

What the automated checks will not do

Alongside each requirement the software runs a narrow factual check against itself.Is the change gate on, is the register complete, are audit records kept for the six months Article 26(6) asks for.Those checks report one of four states, and the fourth matters most: cannot tell.If a ledger is empty, a period cannot be read or no deployment plan exists, the check says so.It never counts itself as a pass.An all-green compliance screen produced by checks that could not run is the failure this apparatus exists to prevent.

The compliance surface

An admin-only compliance interface turns these controls into operations an auditor can run.Filter audit events by type, actor and severity.Export the audit log as JSON or CSV; the export is itself audited.Check hash-chain integrity on demand.Invalidate one user's sessions or all of them.Export a collection's documentation, metadata and chat history for ISO/IEC 27001 A.8.10 portability and deletion.See a status summary of enabled controls.

How to read the status summary.These rows used to be literal true values in code.They are now derived, with an explicit unknown state rather than defaulting to green:

• TLS in transit is read from the scheme of the configured public URL.https reports true, http reports false, an unset URL reports unknown.TLS terminates upstream at the proxy, so there is nothing in-process to measure.This is the best evidence available inside the application.It is configuration-derived, not a network probe.
• Database connection encrypted is true because the application builds its own connection string with encryption on.Certificate validation is reported as a separate row.A self-signed server certificate protects against passive capture but not against active interception.Folding the two into one green tick would overstate it.
• Session revocation is probed, not asserted: the check reads the table the enforcement path actually reads.

What still comes from the customer's own evidence: the proxy's TLS configuration and cipher policy.For an external database, their TDE configuration.Afunana cannot observe either.