Guard

Policy-based access control with 'AI Context Scoping'. Acts as a firewall for LLMs, ensuring agents only see data they are legally allowed to access.

Read Documentation

v1.0

Overview

FintraOS Guard is designed to be the security and governance sentinel. It will ensure that no sensitive data is ever exposed to unauthorised services or users.

Core Responsibilities:

Key Management: Managing Tenant and User encryption keys (Crypto-Shredding).

Consent Registry: Tracking what data a user has agreed to share and for how long.

Access Control: Enforcing Row-Level Security (RLS) and Scope-based access.

View technical specifications in documentation

Core Entities

`ConsentGrant`

Will record the legal basis for processing.

Structure: Consent ID, Profile ID, Tenant ID, Scopes (e.g., READ_ACCOUNTS), Validity Period, Status, and Metadata (IP, User Agent).

`KeyMetadata`

Internal record of encryption keys (keys themselves are in KMS/HSM).

Attributes: Key ID, Entity Type (Profile), Entity ID, Algorithm (AES-256-GCM), Status, and Creation Date.

`IdentityRecord`

The "Master Patient Index" mapping physical humans to digital profiles.

Attributes: Identity ID, Hash Keys (National ID, Passport), Linked Profiles (Tenant + Profile ID), and Confidence Level.

Architecture

Identity Resolution Logic

When a new user signs up, Guard will attempt to match them against the IdentityRecord database.

01. Level 1 (Strong Match): Exact match on National ID + Country. -> Auto-Merge.

02. Level 2 (Medium Match): Exact match on Full Name + DOB + Email. -> Prompt User ("Is this you?").

03. Level 3 (Weak Match): Same Phone Number only. -> Do nothing (could be a family plan).

The "Guard Sidecar"

Every FintraOS microservice (Core, Intelligence, Pulse) will run with a Guard Sidecar.

Incoming: Intercepts API requests -> Validates JWT -> Checks Consent -> Decrypts payload (if authorised).

Outgoing: Encrypts sensitive fields before writing to DB/Event Log.

Benefit: Developers don't handle keys directly; infrastructure handles encryption transparently.

AI Context Scoping (The "Ringfence")

Guard will govern the Context Window for GenAI features. It will ensure the AI only "sees" what the tenant is allowed to see.

* Scenario: Tenant A (NeoBank) asks the AI: "How is this user's financial health?" * Policy Check: * Does Tenant A have READ_GLOBAL_PROFILE scope? * YES: Guard injects data from *all* linked accounts (Credit Cards, Loans from other banks). * NO: Guard filters the Context Window to *only* show data originating from Tenant A. * Mechanism: The Guard Sidecar will intercept the RAG retrieval and apply a hard filter: WHERE tenant_id = 'org_neobank'.

Agent Skill Governance

When the AI Agent attempts to invoke a Skill (e.g., transfer_money), Guard will intercept the request.

* Check 1: Skill Authorisation: Does the Tenant have this Skill enabled? * Check 2: User Consent: Has the user explicitly granted the EXECUTE_TRANSACTIONS scope? * Check 3: Policy Limits: Are the parameters within safe limits? (e.g., "Max Transfer < £500"). * Check 4: Risk Analysis: Calls [[Specs/Module-Intelligence|Intelligence]] to assess if this transaction fits the user's normal pattern.

Events

Deletion Workflow (GDPR)

01.API Call: When a tenant calls DELETE /v1/profiles/{id}.

02.Guard:

Marks ConsentGrant as REVOKED.

Calls KMS to delete the KeyMetadata for that user.

Flushes any cached keys from memory.

01.Result: Data in Vault is now permanent ciphertext.

Interfaces

Access Policy

Will be defined using OPA (Open Policy Agent) or similar.

Example: Allow access if method is GET, path is /v1/forecast, user has READ_FORECAST scope, and tenant ID matches.

Ready to integrate Guard?

Get full access to the Guard SDK and start building the future of finance today.

View Full Specs