Skip to content
§SECURITY / ARCHITECTURE / AUDIT
Governance infrastructure

Governance enforced by design. Mathematically verifiable audit.

Data isolation in the database itself, segregation of duties with risk-based approvals and a history that can't be erased. Closed by default, demonstrable with evidence.

View architecture in technical depthHow governance applies to operations
FIG-01 · CROSS-SECTIONv2026.09
4-layer architectureSCALE 1:1 · LOGICAL
  1. CAMADA 01·APP / FILTER

    Application layer

    Every query passes through institution- and user-level filters before reaching the database.

    BLOCK

    7f4a·9c21

  2. CAMADA 02·DB / ISOLATION

    Database layer

    Policies run inside PostgreSQL itself. They block cross-tenant access even if an application bug attempts to bypass them.

    BLOCK

    ae3d·b5e2

  3. CAMADA 03·AUDIT / CHAIN

    Audit layer

    Append-only log with cryptographic chaining. Any subsequent alteration breaks the chain and is detectable.

    BLOCK

    c407·1fd9

  4. CAMADA 04·APPROVAL / SoD

    Segregation layer

    Sensitive operations pass through one to three approval levels, configured by customer policy.

    BLOCK

    38c2·e06b

§01·THE POSTURE

Three principles that underpin every architecture decision.

Before describing mechanisms, it is useful to state the posture. Without it, every technical item becomes a disconnected detail; with it, every item is a consequence of a prior decision.

  1. 01

    Closed by default

    Access is denied until granted. Absence of an explicit policy is not permission — it is denial. The responsibility to open access belongs to the operator, not the system.

  2. 02

    Two independent barriers

    The application filter is the first. Database-enforced isolation is the second. An exploit in one does not spill into the other: they are decisions made at different points in the stack, for different reasons.

  3. 03

    Auditability is the default

    Every relevant operation is recorded in an immutable history. Governance is demonstrable with evidence, not merely declared in a presentation.

§02·ISOLATION IN TWO BARRIERS

The database refuses because it refuses — not because the application filtered.

When the platform stores a company's data, isolation is guaranteed in two simultaneous layers. They do not replace each other — they operate in parallel, with distinct reasons for existing.

BARRIER 1 · APPLICATION·LAYER 1

Filters every query

Every query passes through institution- and user-level filters before being issued. This is the layer the product team sees and maintains.

OUTCOMECommon failure: a programming bug lets a query through without filtering.
BARRIER 2 · DATABASE·LAYER 2

Refuses even if the application fails

Isolation policies run inside PostgreSQL itself. They do not know the application code and do not trust it. Even if the filter above fails, the database blocks cross-tenant access.

OUTCOMEReason for existing: an application bug must not become a data leak.

The result is concrete: a user with direct database access, using the runtime pool, cannot read data from an institution that is not theirs. The database refuses before the application has a chance to filter.

§03·AUTOMATICALLY APPLIED GOVERNANCE

Forgetting as a failure category.

One of the biggest failure vectors in configurable platforms is the moment when a developer or administrator creates a new table and forgets to apply the correct policies. Yesterday's coverage does not guarantee today's coverage.

At Aether, that moment does not exist. When the platform generates a table associated with an institution, isolation policies are applied automatically — no manual action, no optional step. Coverage growth is organic: each new module inherits governance from the core.

01 / 03·SCHEMA REBUILD
PRE/POST-CONDITION
TRIGGER →
Table is dropped and recreated in a maintenance cycle.
CONDITION →
Table was registered as covered by isolation.
EFFECT →
Policies are automatically reapplied, without manual intervention.
02 / 03·BACKUP RESTORE
PRE/POST-CONDITION
TRIGGER →
Restore replaces the schema with an earlier version.
CONDITION →
Platform governance registry preserved.
EFFECT →
Subsequent recovery step reapplies policies to all tables that had registered coverage.
03 / 03·ACCIDENTAL REMOVAL
PRE/POST-CONDITION
TRIGGER →
Someone attempts to remove or rename a column used by isolation policies.
CONDITION →
An active policy depends on the column.
EFFECT →
The operation is blocked with an explicit error before completing.

Each safeguard is an engineering pre/post-condition, not a human workflow. An accidental operation does not degrade coverage — the system recovers on its own or refuses loudly.

§04·SEPARATION OF DUTIES

Whoever creates a vendor does not approve payment to them.

Separation of duties (SoD) prevents conflicts of responsibility in sensitive operations. At Aether, each sensitive request can require from zero to three approvers, depending on risk and the policy defined by the customer.

  1. N01 · AUTO

    Automatic

    APPROVERS

    No additional approval.

    TYPICAL EXAMPLE
    Low-risk access, within a previously defined profile.

  2. N02 · SIMPLE

    One approver

    APPROVERS

    One area manager.

    TYPICAL EXAMPLE
    Access to operational information of a specific area.

  3. N03 · DUAL

    Two approvers

    APPROVERS

    Area manager + compliance.

    TYPICAL EXAMPLE
    Access with tax or contractual implications that calls for cross-review.

  4. N04 · TRIPLE

    Three approvers

    APPROVERS

    Area manager + compliance + director.

    TYPICAL EXAMPLE
    Access to sensitive data or structural changes to permissions.

The specific policy for each operation is configured by the customer, aligned to the applicable regulatory framework (SOX, ISO 27001, sector-specific policies).

§05·AUDIT WITH MATHEMATICAL VERIFICATION

Governance stops being a declaration and becomes proof.

Every relevant operation generates a record in an immutable history with three properties that allow external verification of the log without trusting the platform that issued it.

  • APPEND-ONLY

    Records do not change

    Once issued, a record cannot be altered or removed. The only permitted operation is append.

  • CRYPTOGRAPHIC CHAINING

    Each block signs the previous one

    Each record includes the signature of the previous one. Any subsequent alteration breaks the chain and is detectable by whoever verifies it.

  • DEDICATED DATABASE

    Separate infrastructure

    Audit runs on infrastructure separate from transactional operations. Operational load does not compete with audit load.

CHAINED BLOCKS · EACH ONE SIGNS THE PREVIOUSFIG-05 · AUDIT CHAIN
  1. #001APPROVE
    7f4a·9c21
    PREV: ∅
  2. #002WRITE
    ae3d·b5e2
    PREV: 7f4a·9c21
  3. #003ACCESS
    c407·1fd9
    PREV: ae3d·b5e2
  4. #004APPROVE
    38c2·e06b
    PREV: c407·1fd9
  5. #005WRITE
    6d18·2a50
    PREV: 38c2·e06b
  6. #006EMIT
    f9b3·4e87
    PREV: 6d18·2a50

The tokens above are illustrative. In the real log, each block contains the signature of the previous one. A broken chain means a detectable alteration. An external auditor can mathematically verify that the log from a specific date has not been altered since issuance.

REGULATORY COVERAGE

How this architecture fits into recognized frameworks.

  • 01

    LGPD

    Complete traceability of access to personal data, minimization in presentation, legal basis recorded per operation.

    ✓ Meets requirements
  • 02

    SOX

    Demonstrable segregation of duties, immutable audit of critical transactions and approvals configurable by risk.

    ✓ Meets requirements
  • 03

    ISO 27001

    Context-based access controls, centralized logging, secrets management aligned with the standard.

    ◐ Compatible architecture · certification on roadmap
  • 04

    SOC 2

    Observability, access management, continuous monitoring of key control points.

    ◐ Compatible architecture · certification on roadmap

LGPD and SOX are legal and regulatory frameworks with capability requirements — the platform meets them. ISO 27001 and SOC 2 are formal certifications: they come after the first operation stabilizes and are not declared before they happen.

§06·LAYERED ACCESS CONTROL

The decision is not a simplistic 'allowed or denied'.

Authorization decisions at Aether pass through multiple combined layers. Each layer answers a different question and, together, they determine whether the operation proceeds, requires approval, or is refused.

  1. L01CONTEXT

    Authenticated user, selected institution, defined operating unit. Without context, there is no decision — the operation is refused for lack of anchoring.

  2. L02ROLE

    What this user can do in the established context. Role is granted, never assumed.

  3. L03ISOLATION

    Within what the role allows, the user sees only data from their institution. Filter in application, enforcement in the database.

  4. L04OBJECT ATTRIBUTES

    A sensitive decision may require additional approval depending on the value, time of day, type of customer, or applicable regulatory framework.

  5. L05AGENT CONTROLS

    If the operation is performed by an AI (Nous), additional controls apply: rate limiting, sensitive content validation and human confirmation before any action.

Practical outcome: the decision is contextual, auditable, and recordable. Every refusal is as traceable as every authorization.

§07·ENCRYPTION AND SECRETS MANAGEMENT

Three fronts handled with equal rigor.

  • AT REST

    Data at rest

    Sensitive data is encrypted with up-to-date algorithms. One key per institution, with no reuse across customers.

  • CERTIFICATES

    Digital certificates

    Each customer operates with their own certificates, stored with cryptographic protection appropriate to the applicable regulatory framework.

  • IN TRANSIT

    End-to-end communication

    Communication between the platform and customers uses up-to-date TLS. Integration with fiscal authorities uses the standards required by those authorities.

§08·WHAT THE AI CAN DO

The AI's vector boundary is written, not declared.

Nous, the platform's AI assistant, does not change data silently. Every action goes through human confirmation — and that rule lives in the product, not in usage posture.

TODAY · CONFIRMED ACTIONS·TODAY

Queries and acts under the user's permissions

The assistant queries data with the same permissions as the user in session and can propose actions. No action runs without confirmation — and sensitive ones require dual approval.

  • No changes on its own initiative
  • Same permissions as the user in session
  • Every query and every action is recorded
IN VALIDATION · EVENT-DRIVEN ACTIONS·IN VALIDATION

Agents that react to the operation

Agents that act on operational events are in validation — always within the same confirmation and approval rules.

  • No silent execution: every action follows the approval rules
  • Actions above value limits require dual confirmation
  • Enabled per company, according to the policy defined by the customer

Relevant for the CIO: the platform's AI does not change data silently. Every action goes through confirmation and is recorded.

§09·WHAT IS STILL BEING BUILT

Honesty about current limits.

Certifications and expansions still to come — described as they are, without claiming them early.

  • 01 / 03
    CAPABILITY

    Formal certifications (ISO 27001, SOC 2)

    Formal certification comes after the first operation stabilizes — and will not be declared before it happens.

    STATUS

    NEXT STEPS · NO SET DATE

  • 02 / 03
    CAPABILITY

    Multi-region

    Each customer's environment runs in a single region. High availability across regions is among the next steps.

    STATUS

    SINGLE REGION · EXPANSION AMONG NEXT STEPS

  • 03 / 03
    CAPABILITY

    Recurring published penetration test results

    Pen testing is a continuous internal policy. Recurring publication of sanitized results is not yet a practice; the cadence decision will be made once there is a qualified external audience demanding it.

    STATUS

    INTERNAL POLICY · NON-RECURRING PUBLICATION

✕END OF DOCUMENT · AETHER ARCHITECTUREv2026.04

Review this architecture with your engineering team.

If the next step is a deep technical dialogue, this is how we begin: document on the table, architect to architect, with no sales layer.

View architecture in technical depthHow governance applies to operations