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 in the Microsoft environment, hosted in Microsoft Azure Australia East.

The Service interacts with Australian bank pricing portals over outbound HTTPS only. No data leaves the Microsoft environment 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 environment, hosted in Microsoft Azure Australia East. Within that boundary:

• All compute runs on Microsoft-managed services with no stored passwords
• All credentials are stored in a Microsoft 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 Client isolation

Each client organisation's deployment enforces a hard organisation guard at startup. The Service rejects any inbound Teams message that does not originate from the expected Microsoft organisation. 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 Microsoft key vault. The Service's compute identity for one client cannot access another client's vault. This is enforced by Microsoft access policies and audited by Microsoft platform logs.

4. Encryption

5. Data Handling

What we store

• Bank portal credentials. Encrypted in the key vault; retained until rotated or deleted.
• Submission history metadata. Encrypted in Microsoft storage; 30-day rolling retention.

What we don't store

• Plaintext credentials anywhere outside the 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 the Microsoft environment in Australia per platform defaults
• Access to logs is limited to authorised SecondBrain Solutions personnel

6. Platform Certifications

The Service runs entirely in the Microsoft environment and therefore inherits Microsoft's compliance posture for its Australian cloud platform:

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 Microsoft platform updates
• Application dependencies are tracked and updated; critical CVEs are addressed promptly
• Microsoft 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 sign-in with multi-factor authentication
• Logged via Microsoft 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

• Key vaults have soft-delete enabled and are being progressively enabled with purge protection for all client vaults
• Microsoft 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.