Security Overview

Last updated: 19 May 2026
Operator: SecondBrain Solutions Pty Ltd trading as Sharp AI
Scope: Bank Pricing Agent by Sharp AI

This Security Overview describes how Bank Pricing Agent by Sharp AI (the "Service") is built, hosted, and operated, and the controls we apply to protect customer information. It is intended for security and procurement reviewers at client organisations.

It complements our Privacy Policy, Terms of Service, and Incident Response Plan.

1. Architecture at a Glance

The Service runs entirely on Microsoft Azure in the Australia East region.

The Service interacts with Australian bank pricing portals over outbound HTTPS only. No data leaves the Azure ecosystem except for these explicitly necessary calls to bank portals on the broker's behalf.

2. Trust Boundary

The trust boundary of the Service is the Microsoft Azure Australia East region. Within that boundary:

• All compute runs in container apps under managed identities
• All credentials are stored in Azure Key Vault with per-client isolation
• All inter-service calls use TLS 1.2+

Outside the boundary:

• Microsoft Teams is the only entry point for broker interaction. Authentication is via the broker's own Microsoft 365 identity.
• Bank pricing portals receive only the loan scenario data and credentials necessary for the specific submission, transmitted over HTTPS.

3. Authentication and Authorisation

3.1 Broker authentication

Brokers authenticate to the Service via Microsoft Teams, using their organisation's Microsoft 365 identity. The Service does not maintain a separate password or user database for brokers. Your existing Microsoft 365 identity controls (including MFA, conditional access, and identity protection) apply.

3.2 Tenant isolation

Each client organisation's deployment enforces a hard tenant guard at startup. The Service rejects any inbound Teams message that does not originate from the expected Entra tenant ID. This is enforced in code, not in policy.

3.3 Per-bank, per-client authorisation

Within each client organisation, the Service maintains a mapping of which brokers are authorised to submit to which banks. Brokers cannot submit to banks they are not authorised for, even if they have credentials.

3.4 Credential isolation

Each client organisation has its own dedicated Azure Key Vault. The Service's compute identity for one client cannot access another client's vault. This is enforced by Azure Key Vault access policies, audited by Azure platform logs.

4. Encryption

5. Data Handling

What we store

• Bank portal credentials. Encrypted in Key Vault; retained until rotated or deleted.
• Submission history metadata. Encrypted in Blob Storage; 30-day rolling retention.

What we don't store

• Plaintext credentials anywhere outside Key Vault
• Bank portal responses beyond the summary captured in submission history
• Personal information from your Microsoft 365 directory beyond what's needed for the bot conversation
• Cookies, browser data, or device fingerprints (the Service is a Teams bot, not a web app)

Logging discipline

• Bank portal credentials are explicitly excluded from application logs
• Loan amounts and broker identifiers are logged for support and audit purposes
• Logs are retained in Azure Log Analytics in Australia East per platform defaults
• Access to logs is limited to authorised SecondBrain Solutions personnel

6. Platform Certifications

The Service runs entirely on the Microsoft Azure platform and therefore inherits Azure's compliance posture for the Australia East region:

The Service has not yet undergone independent third-party penetration testing.

7. Vulnerability and Patch Management

• Container images are rebuilt on a regular cadence to incorporate Azure base image updates
• Application dependencies are tracked and updated; critical CVEs are addressed promptly
• Microsoft Azure platform components are patched by Microsoft per their published cadence
• Identified vulnerabilities are tracked to closure and validated before re-release

8. Access to Production

Access to production environments is limited to authorised SecondBrain Solutions personnel and is:

• Authenticated via Microsoft Entra ID with multi-factor authentication
• Logged via Azure activity logs
• Reviewed periodically

Direct production access is granted only as needed for operational support and is revoked when no longer required.

9. Backup and Recovery

• Azure Key Vault has soft-delete enabled and is being progressively enabled with purge protection for all client vaults
• Azure Blob Storage retains submission history in a single account per client
• Production deployments are reproducible from source-controlled container images, allowing rapid redeployment after infrastructure incidents

10. Subprocessors

The Service is delivered using the following subprocessors. We do not transfer customer data to other third parties.

11. Incident Response

Our process for detecting, containing, and notifying about security incidents is described in our Incident Response Plan. Notifiable data breaches are reported to affected individuals and to the Office of the Australian Information Commissioner per the statutory timeline.

12. Security Contact

To report a security issue, ask procurement questions, or request additional security documentation:

Email: james@secondbrain.com.au
Phone: +61 481 761 659
Mailing address: 11 Cameron Avenue, Artarmon NSW 2064, Australia

We aim to respond to security inquiries within 1 business day.