KB // AI Automation Platform — Deployment Architecture

01

TWO DEPLOYMENT PATHS

The MSP AI Automation platform — dashboards, governance consoles, incident tracking, vendor risk, and Copilot tooling — can be deployed two ways. Both are secure. Both leverage the Microsoft ecosystem. The difference is where the application logic and credentials live, and what that means for compliance certification.

As of the current build, the platform comprises 105 self-contained HTML pages organized across 7 categories: Governance (10 pages), Agents (7), Copilot (5), Operations (4), Dashboards (4), Resources (4), and Tools (3). All 105 pages are hosted on SharePoint and in production today. No page uses a Node.js backend, Express server, or any custom application server. The platform is not a proof of concept — it is a deployed, operational AI automation model.

PATH A · ACTIVE NOW

SharePoint-Hosted

105 pages in production across 7 categories. Authentication uses the engineer's existing Microsoft 365 session. API secrets in Azure Key Vault via Function proxy — never in the browser.

✅

Zero infrastructure to manage

✅

API credentials in Azure Key Vault — browser never sees a key at any point

✅

Full audit trail via Purview Unified Audit Log — already running

✅

DLP + sensitivity labels enforced via Purview — including Copilot

✅

Live governance reporting via Power BI over SharePoint lists

✅

Every service in the stack is Microsoft SOC 2 Type II certified

✅

In production today — no deployment gate

⚠️

Organizational procedures audit still required for formal SOC 2 certification — not a technical gap

PATH B · FUTURE STATE

Azure App Service + Entra ID

Node.js backend on Azure App Service. MSAL confidential client flow. All credentials and API keys stored server-side. More complex — but the same organizational procedures audit applies before formal SOC 2 certification.

✅

Zero credentials exposed to the browser

✅

Full server-side audit trail via App Insights

✅

Granular per-route RBAC via Entra ID groups

✅

Supports complex server-side logic, scheduled jobs, real-time webhooks

⚠️

Custom application code is not covered by Microsoft's certifications — requires separate application-layer audit on top of the organizational procedures audit

⚠️

Weeks of setup and DevOps overhead before first page is in production

02

THE CORE PROBLEM BOTH PATHS SOLVE

The MSP AI platform consoles call third-party APIs (Auvik, ConnectWise, SentinelOne, etc.). Any call made directly from a browser requires the credential to be present in the browser — visible in DevTools network traffic by any engineer who knows to look.

❌ DIRECT FROM BROWSER (UNSAFE)

const API_KEY = 'xxxxxxxxxxxxx';

headers: { Authorization: Basic btoa(user+key) }

// visible in DevTools → Network tab

// any engineer can extract the key

✅ PROXIED (BOTH PATHS SOLVE THIS)

// browser calls: /proxy/auvik/devices

// proxy injects credentials server-side

// DevTools shows only JSON response

// credential never touches the browser

Path A solves this with Azure Functions (the provisioner I built), which acts as a stateless proxy. Path B solves this with a full confidential-client Node.js server. The credential protection outcome is functionally identical for the end user. The difference is in the certification story and the operational complexity.

03

PATH A — HOW SHAREPOINT WORKS

Every page in the platform is a self-contained HTML file uploaded to a SharePoint document library. When an engineer opens a page, SharePoint serves it directly from Microsoft's infrastructure. The page runs entirely in the browser and uses the engineer's existing Microsoft 365 session for any SharePoint list operations.

👤

ENGINEER

Opens page in browser while signed in to M365

📄

SHAREPOINT

Serves HTML file · Session cookie already present · No separate login

📋

SP LISTS

Incident Log · Vendor Risk · Risk Register · Read/write via REST

↓COMPLIANCE + REPORTING LAYER

🔍

MICROSOFT PURVIEW

Unified Audit Log · DLP policies · Sensitivity labels · Every M365 action logged

📊

POWER BI

Governance dashboards · Copilot adoption reporting · Committee evidence packages

🛡

ENTRA ID

MFA · Conditional Access · Group RBAC · Identity governance

↓FOR THIRD-PARTY API CALLS

⚡

AZURE FUNCTION

Stateless proxy · Reads credentials from Key Vault · Forwards request server-side

🔐

KEY VAULT

Auvik API key · Huntress · ConnectWise · Encrypted at rest · Never in browser

🌐

VENDOR APIs

Auvik · SentinelOne · ConnectWise · Actual data returned to dashboard

NO APP REGISTRATION FOR SHAREPOINT OPERATIONS For all SharePoint List reads and writes (incident log, vendor risk, risk register), the platform uses the engineer's existing browser session cookie. No MSAL setup, no app registration, no OAuth flow. The engineer is already authenticated by virtue of being signed in to Microsoft 365. This is why the platform went to production immediately with zero infrastructure work.

PURVIEW — THE AUDIT TRAIL LAYER

Microsoft Purview's Unified Audit Log records every action taken across the entire M365 environment — every SharePoint page opened, every list item created or updated, every Copilot prompt submitted, every DLP policy triggered, every file accessed. This log is retained, tamper-evident, and searchable. When an assessor asks "show me who accessed what and when," Purview is the answer. It is not something you have to build — it is already running in your tenant. You just have to ensure it is enabled and the retention period is configured appropriately for your compliance requirements.

Purview also enforces sensitivity labels and DLP policies across SharePoint, Teams, Outlook, and Copilot. Any document or data item that carries a label cannot be shared or processed in ways that violate the label's rules — even by Copilot. This directly addresses the data classification and protection requirements in CC6.1 and CC6.7.

POWER BI — THE EVIDENCE PACKAGE LAYER

Power BI connects directly to SharePoint lists as a data source. The governance data you are collecting — incidents logged, vendor risk scores, risk register entries, Copilot adoption metrics — becomes a structured reporting layer the moment it lives in SharePoint lists. Power BI dashboards over that data are the committee evidence packages an auditor wants to see: trend lines, open high-severity counts, resolution rates, vendor assessment status. These are not screenshots or manual exports — they are live, auditable reports pulling from the same lists the platform writes to.

Power BI is a Microsoft SOC 2 certified service. Reports built on SharePoint list data extend the inherited compliance coverage to the reporting layer. The Copilot Adoption Dashboard (chancecontra M365 repo, which you were connecting to Graph API via Power BI) is the first concrete example of this — adoption data flowing from Graph into Power BI, surfaced as an auditable adoption report.

For third-party API calls (Auvik, etc.), the Azure Gateway Provisioner creates the Function App proxy in one click. Once provisioned, dashboards call the proxy endpoint instead of the vendor API directly. Credentials live in Key Vault and never reach the browser.

DO I NEED AN AZURE SERVER FOR PATH A? No. Azure Functions and an Azure App Service server are completely different things. The Path A proxy is an Azure Function App on a Consumption plan — serverless, no VM, no always-on process, nothing to patch or manage. It wakes up for milliseconds when a dashboard calls it, reads the credential from Key Vault via Managed Identity, forwards the request, and shuts down. At MSP usage volumes the cost is effectively zero. Path B (the "Azure server") is a Node.js application running on Azure App Service — a persistent server with ongoing infrastructure, a deployment pipeline, and monthly fixed cost. You do not have that and do not need it for Path A. Key Vault requires only the Function App to exist, not a server.

04

PATH A — SOC 2 COVERAGE

Every technical control in this architecture is covered by a Microsoft-certified service. SharePoint, Purview, Power BI, Entra ID, Azure Functions, and Azure Key Vault all carry Microsoft's SOC 2 Type II certification. The API credentials — Auvik, ConnectWise, and any other vendor key — are stored in Azure Key Vault and read by the Azure Function App via Managed Identity. The browser never receives or processes any API key at any point in any workflow. Purview's Unified Audit Log records every action across the stack. DLP policies enforce data handling at the content layer. This is not a partially compliant architecture — every technical control is covered.

The only remaining item is not a technical gap. SOC 2 Type II certification as a certified status requires a third-party CPA firm to audit organizational operating procedures over a defined period — how the change management process is followed, how incidents are handled end-to-end, how access is provisioned and deprovisioned. Microsoft's certifications cover their infrastructure. They do not certify that those procedures were followed last quarter. That organizational audit is what converts "fully compliant architecture" into "SOC 2 Type II certified organization." The platform is already built to produce the evidence that audit requires.

PHYSICAL SECURITY (CC6.4)

COVERED — MICROSOFT

Microsoft's data centers are SOC 2 audited. Physical access controls, environmental controls, and redundancy are documented in Microsoft's audit reports. No action required on your end.

LOGICAL ACCESS CONTROLS (CC6.1)

COVERED — ENTRA ID + SP

SharePoint RBAC, M365 group membership, and Entra ID Conditional Access control who can access each page and list. Purview sensitivity labels enforce what can be done with data after access — including blocking Copilot from processing labeled content in ways that violate the label's rules.

CREDENTIAL & SECRET MANAGEMENT (CC6.3)

COVERED — KEY VAULT

All vendor API credentials are stored encrypted in Azure Key Vault, provisioned via the Gateway Provisioner. The Function App reads them via Managed Identity at request time. The browser never receives or processes any API key — at any point, in any workflow. This is a fully implemented control, not partial.

ENCRYPTION IN TRANSIT + AT REST (CC6.7)

COVERED — MICROSOFT

All traffic is TLS 1.2+. SharePoint, Power BI, and Key Vault encrypt data at rest with Microsoft-managed keys. Purview sensitivity labels persist with data and enforce encryption rules regardless of where the data moves after initial storage.

AVAILABILITY + INCIDENT RESPONSE (A1, CC7)

COVERED

Microsoft's SLA and incident response procedures are part of their SOC 2 report. Your platform's AI Incident Playbook and Incident Log (SP-wired) provide the organizational-layer incident response evidence. Together they cover both the platform and the process.

AUDIT TRAIL & MONITORING (CC7.2)

COVERED — PURVIEW UAL

Purview's Unified Audit Log records every M365 action — page views, list item creates and edits, Copilot prompts, DLP policy triggers, file access — with timestamp and user identity. This is tamper-evident, retained per your policy, and searchable. This is the audit trail an assessor wants to review. It requires no custom development — it is already running in your tenant.

DLP & DATA CLASSIFICATION (CC6.6, CC6.7)

COVERED — PURVIEW DLP

Purview DLP policies govern what can be shared, copied, or processed across Teams, SharePoint, Outlook, and Copilot. Sensitivity labels enforce data handling rules at the content level. This closes the gap between "we have access controls" and "we have data protection controls" — a meaningful distinction for SOC 2 assessors.

EVIDENCE & REPORTING (CC4.1)

COVERED — POWER BI

Power BI connects directly to SharePoint governance lists and produces the committee dashboards assessors expect: incident trends, vendor risk scores, Copilot adoption rates, risk register status. These are live, auditable reports — not screenshots. Power BI is itself a Microsoft SOC 2 certified service.

AVAILABILITY (A1)

COVERED — MICROSOFT SLA

Microsoft's 99.9%+ SLA for M365 and Azure services is documented in their SOC 2 reports. Your platform's availability is bounded by Microsoft's infrastructure commitments.

ORGANIZATIONAL PROCEDURES — CHANGE MGMT, INCIDENT RESPONSE, VENDOR MGMT (CC8, CC9)

NOT A TECHNICAL GAP — REQUIRES FORMAL AUDIT

This is the only remaining item — and it is organizational, not technical. SOC 2 Type II certification requires a third-party CPA firm to audit your procedures over a defined period and confirm they were actually followed: changes approved per your process, incidents handled per the playbook, engineers onboarded and offboarded with access reviews conducted. Your platform produces the evidence for all of these — the Change Request form, Incident Log, Vendor Assessment register, Risk Register. The gap is not that the controls are missing. The gap is that no auditor has yet reviewed the evidence and signed the report.

THE ACCURATE POSITION Every technical control in this architecture is covered by a Microsoft SOC 2 Type II certified service. API secrets are in Key Vault — never in the browser. Every M365 action is logged in Purview. DLP is enforced at the content layer. Power BI provides live, auditable governance reporting. The architecture is technically complete. What remains is a third-party auditor reviewing the operating procedures and issuing the certification. That is the final step — and this platform is already built to produce the evidence it requires.

05

PATH A — CAPABILITIES & LIMITS

Zero infrastructure cost

No servers, no VMs, no containers. The entire platform runs on licensing you already pay for — Microsoft 365 Business Premium or E3/E5 includes SharePoint, Purview, Power BI (via M365 licensing), and Entra ID. The only Azure spend is the Function App proxy (Consumption plan, effectively free at MSP usage volumes).

Immediate production

105 pages already in production. No CI/CD pipeline, no deployment review, no infrastructure provisioning. A new console or governance tool ships in minutes. This is the core speed advantage over Path B.

RBAC through M365

Access control is managed through SharePoint site permissions and Microsoft 365 groups — the same system your team already uses for email and Teams. Purview sensitivity labels add a data-level protection layer on top. No new access control system to maintain or audit.

Full audit trail via Purview

The Unified Audit Log records every action across the entire M365 stack — page access, list edits, Copilot prompts, DLP triggers — with timestamp and user identity. This is the enterprise audit trail an assessor wants, already running, requiring no custom development. This was previously the architecture's weakest compliance point. Purview closes it.

DLP enforced at the content layer

Purview DLP policies and sensitivity labels govern what can be shared or processed, including what Copilot is allowed to do with labeled content. This means compliance controls follow the data, not just the access path.

Compliance inheritance — full stack

SharePoint, Purview, Power BI, Entra ID, Azure Functions, and Key Vault all carry Microsoft's SOC 2 Type II certification. Every layer of the current architecture is covered. The only gap requiring organizational documentation is the change management process.

Power BI as the evidence layer

Power BI connects directly to SharePoint governance lists and produces the live dashboards an assessor or committee expects. Incident trends, vendor risk distribution, Copilot adoption rates, risk register status — these are not manual exports, they are live reports from the same data the platform writes to.

Server-side logic via Azure Functions

SharePoint does not execute server-side code directly — Azure Functions handles that layer. The Function App proxy is built and live. Credential-protected vendor API calls route through it today. Complex backend operations (scheduled jobs, real-time webhooks) follow the same pattern as additional routes are added.

HTML rendering configured

Custom Script setting enabled and configured. HTML files render correctly in the SharePoint tenant. Dependency resolved — not a recurring issue.

06

PATH B — HOW THE AZURE SERVER WORKS

In the Azure server architecture, a Node.js application runs on Azure App Service. The browser never calls third-party APIs or holds credentials — it only calls routes on the same origin server. The server handles authentication via MSAL's confidential client flow, proxies all API calls with server-side credentials, and returns sanitized data to the browser.

👤

ENGINEER

Opens platform URL in browser

🖥

AZURE APP SERVICE

Node.js server · Serves HTML · Handles session · Proxies all API calls

🔐

ENTRA ID

MSAL confidential client · Auth code flow + PKCE · MFA · Conditional Access

↓SERVER-SIDE CREDENTIAL INJECTION

🔑

APP CONFIG / KEY VAULT

All credentials stored server-side · Never sent to browser · Rotated without redeployment

📊

APP INSIGHTS

Every API call logged · User identity · Timestamp · Response code · Anomaly alerts

🌐

VENDOR APIs

Auvik · SentinelOne · ConnectWise · Called server-to-server

WHAT THE BROWSER NEVER SEES Entra ID client secret, Bearer tokens, all API keys, Basic auth credentials. The browser session contains only an httpOnly secure cookie. DevTools network tab shows only /api/auvik/devices returning JSON — identical in appearance to the SharePoint path, but with the full server audit trail behind it.

07

PATH B — ENTRA ID INTEGRATION

Entra ID (formerly Azure Active Directory) is the identity backbone of the Azure server architecture. Unlike the SharePoint path where authentication is implicit through the browser session, Path B uses a formal confidential client application registration with explicit permission scopes and group-based access control on every request.

APPLICATION REGISTRATION

An app registration is created in Entra ID representing the server application. It is configured as a confidential client — meaning it has a client secret that never leaves the server. The registration defines which Microsoft Graph scopes the application can access and which users are allowed to authenticate to it.

Client ID

The application's unique identifier in your tenant. Used in the MSAL configuration on the server. Safe to include in server-side code.

Client Secret

The application's credential. Stored in Azure App Service Configuration or Key Vault. Never sent to the browser. Rotated on a schedule.

Redirect URI

The server-side callback URL where Entra ID returns the authorization code after login. Must exactly match a URI registered in the app registration.

API Permissions

The specific Microsoft Graph scopes the app can request: User.Read, Group.Read.All, Sites.Read.All, and any other platform-specific permissions. Requires admin consent from a Global Admin.

AUTH FLOW — STEP BY STEP

The confidential client uses the Authorization Code flow with PKCE. This is the same flow Microsoft uses for Azure Portal, Teams, and SharePoint itself.

STEP	WHO ACTS	WHAT HAPPENS
1	Browser	Engineer navigates to the platform URL. Server detects no valid session.
2	Server	Redirects browser to Entra ID login with client_id, scope, and PKCE code challenge.
3	Entra ID	Presents Microsoft login. Engineer authenticates. MFA and Conditional Access are enforced here.
4	Entra ID	Returns an authorization code to the server's redirect URI.
5	Server	Exchanges auth code + client secret + PKCE verifier for access token and refresh token. Tokens stored server-side only.
6	Server	Creates a session for the engineer. Sets httpOnly secure session cookie in browser response.
7	Browser	Subsequent requests carry the session cookie. Server validates session and checks group membership before processing each request.

GROUP-BASED ACCESS CONTROL

On every authenticated request, the server calls Microsoft Graph to verify the engineer's group membership. This enables role-based access that goes beyond SharePoint site permissions — different routes can be locked to different Entra ID groups. For example, automation scripts in Console 3 can be restricted to a Security Engineer group while the operations dashboards are open to all NOC staff. This control is enforced server-side and cannot be bypassed from the browser.

08

PATH B — SOC 2 REQUIREMENTS

The Azure server architecture is technically strong. Azure, Entra ID, and Key Vault are all Microsoft SOC 2 certified — those layers are covered. The difference from Path A is that Path B introduces custom-built application code: the Node.js server, session management, proxy routes. That code is not covered by Microsoft's certification and adds an additional audit requirement on top of the organizational procedures audit both paths share.

Platform Infrastructure

100%

Credential Security

100%

Identity & Access Control

100%

Audit Trail & Logging

100%

Custom App Code Audit

Pending

Org Procedures Audit

Pending

WHY PATH B HAS A HIGHER AUDIT BURDEN THAN PATH A Azure, Entra ID, and Key Vault hold SOC 2 Type II for their infrastructure and services — those layers are covered exactly as they are in Path A. The additional requirement in Path B is that the custom Node.js application code — the server logic, proxy routes, session management — is software you wrote. No Microsoft certification covers it. Before formal SOC 2 certification, a qualified assessor needs to review that code, the deployment process, and the operational controls specific to this application. Path A has no custom application server code, so it does not carry this requirement. Both paths still need the same organizational procedures audit. Path B just has an extra layer on top.

INFRASTRUCTURE (CC6)

COVERED — AZURE

Azure App Service, Key Vault, and App Insights run on Microsoft's SOC 2 certified infrastructure. Same coverage as Path A's Azure Functions and Key Vault.

AUTHENTICATION (CC6.1)

COVERED — ENTRA ID

Entra ID's authentication service is SOC 2 certified. MFA, Conditional Access, and token lifecycle management are covered. Same Entra ID coverage as Path A.

CUSTOM APPLICATION CODE (CC8)

REQUIRES OWN AUDIT

The Node.js server, proxy routes, and session logic are custom-built software. Microsoft's certifications do not extend to custom code. This is the additional audit requirement that does not exist in Path A.

ORGANIZATIONAL PROCEDURES (CC9)

SAME AS PATH A — PENDING

The organizational procedures audit — change management, incident response, onboarding and offboarding — applies to both paths equally. This is not unique to Path B. It is the final step for either architecture.

09

PATH B — CAPABILITIES & LIMITS

Zero credentials in browser

Every API key, client secret, and auth token lives on the server. The browser session contains only an httpOnly secure cookie. This is the architecturally cleanest credential posture available for a web application.

Full audit trail

App Insights logs every API call with timestamp, user identity (from the session), endpoint, parameters, and response code. This is audit trail evidence that an assessor can review in a structured format — more complete than SharePoint's built-in change tracking.

Server-side logic

Unlike SharePoint, the Azure server can run complex backend operations: scheduled jobs, real-time webhooks from vendor platforms, data transformation and aggregation, multi-step workflow automation. No client-side computation limits.

Granular Entra ID RBAC

Group-based access control enforced server-side on every request. Individual routes can be locked to specific Entra ID groups. Conditional Access policies (device compliance, named location, risk score) apply to every session.

Weeks before production

Infrastructure provisioning, app registration setup, Node.js server development, deployment pipeline, and testing all happen before the first page is live. The SharePoint path was in production same day. The Azure server path has a meaningful setup runway.

Additional application-layer audit required

Both paths need the same organizational procedures audit for SOC 2 certification. Path B adds a second requirement on top: a qualified assessor reviewing the custom Node.js application code, the deployment pipeline, and the operational controls specific to that application. This does not exist in Path A because Path A has no custom application server code.

Ongoing operational cost

An App Service plan (B1 or P1v3) has a monthly fixed cost of $13–$80/month depending on tier. There is also DevOps overhead: patching Node.js, managing the app registration, rotating secrets, and monitoring the service.

10

SIDE-BY-SIDE COMPARISON

CRITERIA	PATH A — SHAREPOINT	PATH B — AZURE SERVER
Time to production	Now — already live	Weeks of setup
Infrastructure cost	Included in M365 licensing	$13–$80/month App Service + DevOps time
Credentials in browser	No — Azure Function proxy for vendor APIs	No — all server-side
SOC 2 platform cert	Inherited from Microsoft 365	Inherited from Azure + Entra ID
Application-layer cert	Not required — no custom app server	Required — custom Node.js code is not covered by Microsoft's certifications
Audit trail	Purview Unified Audit Log — every M365 action logged with user identity and timestamp	App Insights — every request logged with user identity
DLP / data classification	Purview DLP policies + sensitivity labels enforced across all M365 services including Copilot	Application-layer DLP would need to be custom-built
Compliance reporting / evidence	Power BI over SharePoint lists — live committee dashboards, adoption reports, risk trends	Custom reporting would need to be built on top of App Insights or a separate data store
Access control	SharePoint RBAC + M365 groups	Entra ID groups + Conditional Access (more granular)
Server-side logic	Azure Functions — proxy live, stateless execution	Full Node.js server — scheduled jobs, webhooks, complex workflows
Change deployment	Upload HTML file — immediate	Deploy code to App Service — requires CI/CD or manual deployment
Operational overhead	Minimal — SharePoint handles hosting	Node.js patching, secret rotation, deployment pipeline maintenance
Certification story for clients	Point to Microsoft's SOC 2 trust center — done	Point to Azure + Entra + "custom application under review" — incomplete

11

RECOMMENDATION

STRATEGIC RECOMMENDATION

Continue on SharePoint. With Purview and Power BI in the stack, this is not a compromise — it is a fully compliant production architecture.

The addition of Microsoft Purview and Power BI changes the compliance picture materially. The audit trail gap — previously the weakest point of the SharePoint architecture — is closed by Purview's Unified Audit Log, which records every M365 action across every layer of the stack with no custom development required. Purview DLP policies extend data protection to the content level, including governing what Copilot can do with labeled data. Power BI turns SharePoint governance list data into structured, live committee evidence packages. Every layer — SharePoint, Purview, Power BI, Entra ID, Azure Functions, Key Vault — carries Microsoft's SOC 2 Type II certification.

The platform is 105 pages, across 7 operational categories, in production today. Stage 1 POC is complete — the Azure Function App proxy is built and active, credentials are secured in Key Vault, and no API key touches the browser at any point in any workflow. Stage 2 is underway. The only remaining compliance item is the organizational procedures audit — which the Change Request form, Incident Log, Vendor Assessment register, and governance tooling already produce the evidence for.

The Azure server architecture is still a genuine long-term evolution. Richer server-side logic, granular per-route RBAC, and the ability to run scheduled jobs and real-time webhooks are all real advantages for future phases. But the case for moving to it immediately is now significantly weaker — not because the Azure server is less secure, but because the SharePoint path with Purview and Power BI is more complete than it was. The remaining delta is server-side complexity and a custom application audit, not a compliance gap. Build on what is working. Measure the business impact. Use that evidence to justify the Azure investment when the functionality requirements demand it.

12

ROADMAP

The two timelines below are independent. Path A is the current active build. Path B shows what was developed before the strategic pivot and what would be required if that path were ever resumed.

PATH A · CURRENT

SHAREPOINT PLATFORM

✓

COMPLETE

STAGE 1 — POC

105-page platform deployed across 7 categories. Governance, dashboards, Copilot tooling, operations consoles, and AI governance framework all live. Azure Function App proxy deployed and active. Key Vault credentials inject server-side on every vendor API call.

Production dashboards call the Function App proxy URL. Browser never sees an API key at any point in any workflow.

2

IN PROGRESS

STAGE 2 — LIVE DATA

Wire governance tools to live SharePoint lists (Incident Log, Vendor Risk Register, Risk Heatmap, Cost Tracker). Connect Power BI to SharePoint list data for live governance dashboards. Enable Purview Unified Audit Log retention policy.

SP list wiring pre-built into tools via SP_CONFIG pattern. Power BI to Graph API and SP lists established.

3

PLANNED

STAGE 3 — EXPANSION

Expand vendor API proxy to additional platforms (ConnectWise, SentinelOne, Huntress). Formalize Purview DLP label policies. Begin organizational procedures documentation for SOC 2 audit readiness.

Infrastructure already in place — configuration and process work, not build work.

PATH B · DEVELOPMENT HISTORY + OPTIONAL FUTURE

AZURE SERVER

✓

COMPLETED

B1 — LOCAL PROXY SERVER

Built Node.js local proxy (main.js) solving browser credential exposure for vendor APIs. Session cookie capture, Basic auth injection, and API forwarding for SPX and Auvik — implemented and working locally.

Validated the proxy pattern the Azure Function approach later inherited.

✓

COMPLETED

B2 — CREDENTIAL MANAGER

Per-vendor credential storage, session management, cookie handling for session-based APIs (SPX), and Basic auth for key-based APIs (Auvik). Multiple vendor integrations wired and operational.

Credential isolation pattern is the same one Key Vault implements in the Azure Functions path.

⟳ PIVOT — SHAREPOINT PATH ADOPTED

Strategic decision to move to SharePoint + Azure Functions. SharePoint inherits Microsoft SOC 2 certification across the full stack, eliminates infrastructure overhead, and enables immediate production deployment. Credential security outcome is identical — Key Vault + Function proxy replaces the local proxy server.

B3

NOT REQUIRED

AZURE APP SERVICE

Deploy Node.js on App Service. Configure Entra ID as confidential client (MSAL auth code + PKCE). Migrate credential management to server-side Key Vault references. Configure App Insights for full audit trail.

Starting point if Path B is ever resumed. B1–B2 is the proven architecture to build from.

B4

NOT REQUIRED

ENTRA ID GROUP RBAC

Server-side access control enforced per route. Consoles locked to specific Entra ID security groups. Conditional Access policies at session level — device compliance, named location, risk score.

Only relevant if per-route RBAC beyond SharePoint group permissions is a client requirement.

B5

NOT REQUIRED

CUSTOM APPLICATION AUDIT

Qualified SOC 2 assessor reviews the custom Node.js code, deployment pipeline, and application-specific operational controls. This is in addition to the organizational procedures audit both paths require.

Unique to Path B. Path A has no custom application server code.

THE MESSAGE WHEN PRESENTING THIS TO CLIENTS OR LEADERSHIP "I have deployed the AI automation platform across 105 pages on Microsoft 365 infrastructure. Stage 1 is complete — the platform is fully operational, the Function App proxy is live, and no API credentials exist in the browser at any point in any workflow. Stage 2 is underway. Every layer of my stack — SharePoint, Microsoft Purview, Power BI, Entra ID, Azure Functions, and Azure Key Vault — carries Microsoft's SOC 2 Type II certification. Purview's Unified Audit Log records every action on the platform with full user attribution. Purview DLP policies govern data handling including what Copilot is allowed to process. Power BI gives me live governance reporting and committee evidence packages directly from my operational data. My internal AI governance framework — committee structure, change requests, incident procedures, vendor risk tracking, and acceptable use policy — provides the organizational controls that complete the picture. The compliance foundation is stronger than most custom-built alternatives that are still going through their first audit cycle, and I have full visibility into how the platform is being used."