How Sharp Works
This page explains what kind of automation Bank Pricing Agent by Sharp AI (the "Service") actually is, and answers the questions a bank, aggregator or brokerage security team asks before approving it. It is written for reviewers, not buyers.
For hosting architecture, encryption and subprocessors, see the Security Overview. This page complements it, along with our Privacy Policy, Terms of Service and Incident Response Plan.
Two things to establish before the specifics.
First, this is Attended Robotic Process Automation (A-RPA) — a category the Commonwealth Bank actively recommends to its own business customers, pointing them to UiPath and Microsoft Power Automate.1 A broker starts every request, it runs under their own login and permissions, and MFA is completed by them personally.
Second, we sit inside the Microsoft family: Teams, Entra ID, Azure, Key Vault, Australia East. Think of it as Microsoft Power Automate, which could do this but not at this scale — Power Automate runs inside a single organisation's tenant, whereas Sharp is built on the Microsoft Partner approved Microsoft Teams model.
1. Attended, Not Unattended
The most common misconception in a security review of this Service is that it is screen scraping. It is not, and the distinction is a formal industry category rather than a label we invented — Microsoft defines and prices attended and unattended automation separately.10
| Unattended RPA | Attended RPA — what Sharp is | |
|---|---|---|
| Trigger | Runs on a schedule, no human present | Triggered by a person, every time |
| Identity | Its own bot identity or service account | The broker's own identity and permissions |
| Permissions | Often elevated beyond any individual user | Can do nothing the broker could not do themselves |
| Governance profile | The category carrying governance risk; this is what screen scraping is | Bounded by your existing identity controls |
The attended/unattended distinction used here is UiPath's, the definition used across the RPA industry.2
1.1 What that means in practice
- No scheduler, no service account, no bot identity on any lender portal. Every session exists because a named broker asked for it.
- Agentless. Nothing is installed anywhere — no agent, no browser extension, no desktop software, on our machines or yours.
- MFA is completed, not bypassed. The code comes from the broker's own mailbox or handset, and the broker completes the challenge personally.
- Broker-scoped authority. The automation operates with exactly the access the broker already holds at that lender. It cannot reach a portal, product or client the broker could not reach by hand.
- No password held with us. Sign-in is your own Microsoft 365 identity, so your MFA and organisational conditional access apply unchanged.
1.2 Why this matters for screen-scraping policy
Screen scraping is under active regulatory scrutiny in Australia. Treasury has consulted on its policy and regulatory implications,5 the Commonwealth Bank has publicly argued for its removal from the Consumer Data Right,6 and mandatory MFA has made credential-sharing approaches increasingly unworkable.7 The practice at issue in all three is the unattended pattern: a third party holding a consumer's credentials and logging in as them, without them present, under an identity that is not theirs.
Sharp does not do that. The broker is present, the identity is theirs, and the MFA challenge is answered by them.
2. Credentials at Runtime
This is the control reviewers scrutinise most closely, so it is set out in full. The pattern is the same one used by UiPath and Power Automate credential stores — standard enterprise RPA, not something bespoke.3
2.1 For most lenders, we never see the password
We pass a reference to your own vault, and the automation retrieves the credential directly. The plaintext value does not pass through a person, a console, or a support process.
2.2 Where a credential is handled in-process
- Fetched at the moment of use, through a connection created for that single request and closed immediately afterwards
- Never cached between requests
- Never written to disk
- Never placed in an environment variable
- Never logged
2.3 Where credentials live
- A dedicated Azure Key Vault per firm. The compute identity for one client cannot reach another client's vault.
- HSM-backed keys and managed identities. No vault key exists in application code or configuration.
2.4 Audit record
Every credential access is audited with actor, lender, outcome and timestamp. The record stores only a truncated fragment of the username and never the password.
3. Retention and Secure Deletion
| Data | Retention |
|---|---|
| Bank portal credentials | Held in your vault until rotated or deleted, with soft-delete recovery enabled |
| Submission history | See the Security Overview for current retention |
| Credential audit trail | 7 years, deliberately retained for dispute resolution |
| Client credit data | Not applicable — never collected |
That last row is the material point for a credit-data risk assessment: there is no credit data to delete. Income, employment, tax file numbers and credit files never enter our system. The credit assessment stays in your systems. We hold pricing scenarios, not client files.
3.1 Hard deletion on termination
Deprovisioning is a single operation: vault purge, audit records, whatever submission history is held at that time, and a written deletion certificate. We are willing to commit to this contractually.
It is a materially smaller job than deprovisioning a CRM, for the reason above: we hold pricing scenarios, not client files.
4. What We Hold, and What We Don't
4.1 Certifications
SecondBrain Solutions holds no security certification of its own. Our Microsoft Partner Center record states SOC 2: No and ISO 27001: No, consistently.
The certifications listed in the Security Overview — ISO/IEC 27001, ISO/IEC 27018, SOC 2 Type II, IRAP PROTECTED — are Microsoft's, for the Azure platform we run on, and each is marked there as inherited from the Azure platform. We inherit that platform posture and nothing more.
4.2 Independent audit
None held, and none currently in progress.
What we do have instead: CI-gated verification on every change, zero-traffic canary deploys, a named rollback target, and a recorded verdict for every release.
4.3 Penetration testing
We have never commissioned one. We are equally happy for your own security team to test us directly.
The scope is small: one authenticated endpoint, no public website, no consumer login.
5. Application Security Testing
5.1 Static analysis (SAST) — the relevant discipline, and we do it
- Secret scanning on every push.
- Static analysis guards enforcing credential-handling and data-isolation invariants, each drawn from a real incident.
- A build allowlist, so only named application directories enter the production image.
- Microsoft Defender for Cloud protection plans across Key Vault and Resource Manager.
- Automated dependency and CVE scanning is being added.
5.2 Dynamic analysis (DAST) — largely not applicable
Dynamic scanning probes public web applications, and we publish none. Our only ingress is an authenticated service endpoint validating a Microsoft-signed token. There is no anonymous surface to scan.
6. Release Management and Configuration Consistency
A small correction to the premise of the usual question: there are no separate customer deployments. Configuration consistency is structural — one build, one configuration, no per-customer drift.
Isolation sits at identity and credentials instead: a dedicated Key Vault per firm, and a Microsoft-signed tenant claim resolved on every request.
6.1 Patching and security governance
- One pipeline. Security patches are not a separate lane — same gates, same evidence, same rollback.
- Azure platform components are patched by Microsoft on their published cadence.
- Defender for Cloud monitors the subscription for threats and misconfiguration.
- Automated dependency alerts are being added to trigger that pipeline.
6.2 Key-person and continuity risk
Nothing depends on an individual's machine or knowledge. The platform runs entirely on managed Azure services and is reproducible from source control. There is no bespoke hardware, no local environment, and no undocumented deployment step.
This is a question your own operational risk obligations may require you to ask of material service providers.11
7. Microsoft Azure, Not Google Cloud
Reviewers occasionally ask why our security documentation says Azure when other correspondence has mentioned Google Cloud. To be unambiguous: the Security Overview is correct for a Microsoft Teams deployment. Your instance runs entirely on Microsoft Azure (Australia East), with Microsoft Teams as the interface and Microsoft Entra ID for identity.
No component of your service runs on Google Cloud, and no data or credential of yours resides there. There is no deployment into any Google environment.
The underlying product is one application codebase that can be deployed to more than one hosting environment. A customer using Google Workspace rather than Microsoft 365 would be served from the Google-hosted deployment. That is a separate deployment; it is not yours, and the two do not share credentials or data.
8. Where Standard Controls Do Not Apply
Security questionnaires are usually written for a consumer-facing web application. Several standard controls have no meaningful equivalent in this architecture. We would rather say so than claim a control we do not operate.
| Control | Why it does not apply |
|---|---|
| Web application firewall | We publish no web application, so there is no anonymous surface for one to protect |
| Dynamic application scanning | Same reason: no public site, no anonymous entry point, no forms to probe |
| Consumer account security and end-user MFA | Borrowers have no account, login or credential with us |
| Endpoint and device controls | Nothing is installed on any machine, ours or yours |
| Sensitive consumer data handling | The credit assessment never reaches us. It stays in your systems |
9. 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.
10. References
About UiPath
UiPath is the world's largest specialist robotic process automation vendor, listed on the New York Stock Exchange (PATH). It was named a Leader in Gartner's Magic Quadrant for Robotic Process Automation for the seventh consecutive year in 2025, ranked highest for Ability to Execute.4 It is one of the two products CBA's own guidance points its business customers toward, alongside Microsoft Power Automate, and it is UiPath that defines the attended-versus-unattended distinction used in section 1.
- Commonwealth Bank — Robotic process automation, CBA Brighter Perspectives. commbank.com.au
- UiPath — Attended automations (governance and permissions guidance). docs.uipath.com
- UiPath — Guidance for credentialing robots and managing their access. UiPath Robot ICAM Guidance (PDF)
- UiPath — Recognised as a Leader in the 2025 Gartner Magic Quadrant for RPA. uipath.com
- Australian Treasury — Screen scraping: policy and regulatory implications (consultation). treasury.gov.au
- iTnews — CBA's Comyn wants screen scrapers scrubbed from Consumer Data Right. itnews.com.au
- CommBank MFA and the end of screen scraping — mandatory multi-factor authentication, March 2025. blog.fiskil.com
- Microsoft — Power Platform cross-tenant restrictions. learn.microsoft.com
- Microsoft — Tenant restrictions for Power Automate desktop machine registration. learn.microsoft.com
- Power Automate pricing 2026 — per-bot licensing for concurrent unattended processes. automationatlas.io
- McCullough Robertson — CPS 230 compliance countdown: material service providers. mccullough.com.au