Breaking the Compliance Wall: Building Visual MCP UI Apps for FedRAMP & HIPAA with OSCAL
Discover how MCP UI Apps are transforming government compliance from endless text forms into interactive, visual experiences powered by OSCAL standardization and the Model Context Protocol.
The Compliance Text Wall Problem
If you've ever worked on a FedRAMP authorization or HIPAA compliance project, you know the feeling. You open that 800-page System Security Plan document, your cursor hovering over the search function, desperately trying to find the one control implementation detail buried somewhere in section 12.4.3. Your eyes glaze over. The text blurs. You wonder if this is what purgatory feels like.
Government compliance documentation has been stuck in the dark ages for decades. We're talking about massive Word documents passed around via email, sprawling Excel spreadsheets with broken formulas, and PDF artifacts that seem to have been scanned, printed, and rescanned approximately seventeen times. The irony isn't lost on anyone: we're using 1990s document technology to secure 2020s cloud infrastructure.
But something interesting is happening at the intersection of AI agents, standardized compliance data, and modern web interfaces. The Model Context Protocol has evolved beyond simple text exchanges, and OSCAL has finally given us a machine-readable lingua franca for compliance. Together, they're creating something remarkable: MCP UI Apps, interactive visual compliance experiences that actually make sense.
This isn't just about making compliance prettier. It's about fundamentally reimagining how humans and AI collaborate on complex regulatory workflows. Let me show you how.
What Are MCP UI Apps?
The Model Context Protocol started as a way for AI agents to interact with external tools and data sources through a standardized JSON-RPC interface. It was elegant in its simplicity: agents could call tools, receive structured responses, and take action. But there was a problem. Everything was text.
When you asked an agent about your FedRAMP compliance status, it would respond with a wall of text describing which controls were implemented, which were pending, and which needed attention. For simple queries, this worked fine. But for complex compliance workflows involving hundreds of interconnected controls, inheritance relationships, evidence artifacts, and assessment results, pure text became overwhelming fast.
MCP UI Apps solve this by introducing a standardized way for MCP servers to deliver interactive user interfaces directly into the agent conversation flow. Think of it as the protocol learning to speak in pictures, dashboards, and interactive components instead of just words.
The architecture is deceptively simple. MCP servers pre-register UI resources using a ui:// URI scheme. These are HTML templates that live on the server side, reviewed and validated by the host application before they're ever displayed. When an agent needs to show complex data (say, a compliance dashboard with dozens of control status indicators) it references one of these UI resources instead of trying to describe everything in text.
The UI components themselves run in sandboxed iframes, completely isolated from the host application for security. They communicate back to the agent using the same JSON-RPC protocol that powers everything else in MCP, but over postMessage instead of the main transport channel. This means developers can use familiar web technologies (HTML, CSS, JavaScript) while maintaining the security and auditability that enterprises require.
What makes this particularly powerful is the intent-based control model borrowed from modern UI frameworks. When a user clicks a button in your compliance dashboard, the component doesn't directly modify state or make API calls. Instead, it bubbles up an intent ("view_control_details" or "generate_poam_entry") that the agent interprets and acts on. This keeps the AI in the loop while still enabling rich, responsive interfaces.
The result is what the MCP spec calls an "agentic app runtime," a foundation for novel interactions between AI models, users, and applications. For compliance workflows, this changes everything.
Enter OSCAL: The Standard That Makes Automation Possible
The Open Security Controls Assessment Language represents NIST's ambitious attempt to solve one of cybersecurity's most persistent problems: the complete lack of interoperability in compliance documentation. Before OSCAL, if you wanted to demonstrate that your system met NIST 800-53 controls for a FedRAMP authorization, you'd create a massive Word document with control descriptions copy-pasted from the baseline, your implementation details added in another font, and evidence references scattered throughout. If you later needed to show SOC 2 compliance, you'd start over from scratch, even though many of the underlying controls overlapped significantly.
OSCAL provides a set of machine-readable JSON and XML schemas that model the entire compliance lifecycle. It defines eight core document types, each serving a specific purpose in the governance, risk, and compliance workflow.
The catalog model represents a structured collection of controls (think NIST 800-53, HIPAA Security Rule, or the CIS Critical Security Controls). Each control has a unique identifier, structured parameters, assessment procedures, and relationships to other controls. The profile model builds on catalogs by selecting specific controls and tailoring them for particular use cases. FedRAMP baselines, for example, are profiles that select and customize NIST 800-53 controls for cloud service providers at low, moderate, and high impact levels.
The mapping-collection model solves a problem that has plagued compliance professionals for years: demonstrating how controls in one framework relate to controls in another. With OSCAL mappings, you can show that implementing NIST 800-53 AC-2 (Account Management) also satisfies HIPAA 164.308(a)(3)(i) and CIS Control 5.1. This isn't just convenient it's transformative for organizations dealing with multiple compliance frameworks simultaneously.
Moving into implementation, the component-definition model describes how specific software components, services, or organizational processes implement controls. This is where the rubber meets the road. Your patient records API, for instance, might implement AC-2 through AWS IAM integration, automated account provisioning, and audit logging to CloudWatch. All of this gets structured in machine-readable format, ready for automation.
The system-security-plan (SSP) brings everything together, documenting how your entire system all its components, inherited controls from cloud providers, and custom implementations meets the required security baseline. The assessment-plan, assessment-results, and plan-of-action-and-milestones (POA&M) models complete the lifecycle, providing structured formats for assessment activities and remediation tracking.
Why does this matter for MCP UI Apps? Because when your compliance data is in a standardized, machine-readable format, you can finally automate the workflows that have always been painfully manual. You can query your infrastructure-as-code to automatically populate component definitions. You can run continuous assessments that feed directly into OSCAL assessment results. You can visualize control implementation status in real-time. And you can do all of this through AI agents that understand the OSCAL data model and can surface exactly the right information at exactly the right time.
A Real-World Example: HIPAA Compliance Dashboard
Let me paint you a picture of what this looks like in practice. Imagine you're building a healthcare platform (maybe a telemedicine service or an EHR integration layer). HIPAA compliance isn't optional, and the regulations are extensive. The HIPAA Security Rule alone contains dozens of required and addressable implementation specifications spanning administrative, physical, and technical safeguards.
The traditional approach to demonstrating HIPAA compliance involves creating a detailed narrative document mapping each Security Rule provision to your system's controls. You'd write pages explaining how 164.308(a)(1)(i), the Security Management Process, is implemented through your risk analysis procedures, sanction policies, and information system activity review. You'd describe your encryption implementations for 164.312(a)(2)(iv). You'd document your access control mechanisms for 164.308(a)(4). The document would grow to hundreds of pages, and updating it as your system evolved would be a quarterly ordeal.
With OSCAL and MCP UI Apps, the workflow transforms entirely. Your system's components are defined in OSCAL component-definition documents. Each component (the patient API gateway, the database layer, the authentication service) specifies exactly which controls it implements and how. These definitions live as structured data, not narrative prose.
{
"component-definition": {
"uuid": "f8a3c2e1-7d6b-4a92-bc45-8f2e1d3a9c5b",
"metadata": {
"title": "Telemedicine Platform Components",
"last-modified": "2026-01-08T10:00:00Z",
"version": "3.2.0"
},
"components": [{
"uuid": "7b9d4f2a-1c3e-4d8b-9a2f-6e5c8d1b7a3f",
"type": "software",
"title": "Patient Records API Gateway",
"description": "RESTful API service providing secure access to patient health records with role-based access control and comprehensive audit logging.",
"control-implementations": [{
"uuid": "5c8a3e2b-9d1f-4a7c-8b5e-2d6f9a3c1e8b",
"source": "https://healthcare.gov/hipaa-security-rule",
"implemented-requirements": [{
"uuid": "9e2f7a5c-3d1b-4a8e-7c5b-8e2a6d9f3c1b",
"control-id": "164.312(a)(1)",
"description": "Access control mechanisms implemented through AWS Cognito integration with role-based permissions enforced at API gateway layer. MFA required for all administrative access. Session timeout set to 15 minutes of inactivity.",
"props": [{
"name": "implementation-status",
"value": "implemented"
}],
"responsible-roles": [{
"role-id": "security-engineer"
}]
}]
}]
}]
}
}
This isn't documentation for humans to read; it's data for systems to process. An MCP server connected to your OSCAL repository can expose tools that query this data, aggregate it, and present it however makes most sense for the current context.
When your AI agent needs to show HIPAA compliance status, it doesn't generate a text summary. Instead, it invokes a UI resource that renders an interactive dashboard. The dashboard queries the OSCAL data through MCP tools, showing real-time status for each Security Rule provision. Controls that are fully implemented display with green indicators and links to evidence artifacts. Controls in progress show current assignees and expected completion dates. Controls with findings display the related POA&M entries with remediation timelines.
The user can drill into any control to see the detailed implementation narrative, the specific components involved, and the evidence that supports the implementation claim. If they need to generate a report for auditors, the agent can produce it on demand from the same structured data, formatted exactly how the auditor needs to see it. If infrastructure changes affect a control implementation, the dashboard updates automatically because it's querying live OSCAL data, not static documents.
This is the fundamental shift: compliance becomes a continuous, data-driven process rather than a periodic documentation exercise.
FedRAMP: From Audit Pain to Automation Bliss
FedRAMP takes everything difficult about compliance and amplifies it. The program was created to standardize security assessments for cloud services used by federal agencies, which is admirable. But the reality of obtaining and maintaining a FedRAMP authorization is notoriously complex.
A FedRAMP High baseline requires implementing 325 security controls with extensive documentation requirements. You need a System Security Plan that details every aspect of your architecture, a Security Assessment Plan describing how each control will be tested, and Security Assessment Results documenting the findings. Then comes continuous monitoring monthly vulnerability scans, quarterly penetration tests, annual assessments, and monthly POA&M submissions to the FedRAMP PMO.
The traditional workflow for managing this is brutal. When an auditor asks about the status of AC-2 (Account Management), a team member opens the 800-page SSP, uses the search function, finds fourteen different references to AC-2 scattered across the document, and tries to piece together the current implementation status. When infrastructure changes, someone needs to update multiple sections of the SSP manually. When a security scan finds an issue, someone creates a POA&M entry in Excel and emails it around for review.
MCP UI Apps with OSCAL change this workflow fundamentally. The agent becomes an intelligent interface to your compliance posture, able to answer questions instantly with visual, interactive responses.
When someone asks about AC-2, the agent doesn't search through documents. It queries your OSCAL system-security-plan for AC-2 implementation details, checks your assessment-results for recent findings, and pulls evidence from your continuous monitoring tools. In seconds, it presents a visual breakdown showing implementation status, responsible roles, evidence sources with timestamps, inherited controls from your cloud provider, and any open findings with remediation status.
The visual component is critical here. A text description of AC-2 status requires reading through paragraphs of implementation narrative, mentally tracking which parts are your responsibility versus inherited, and cross-referencing evidence artifacts mentioned in different sections. A visual UI component can show all of this at a glance: a status indicator, a clear separation of customer versus provider responsibilities, clickable evidence links with dates, and any related POA&M entries displayed inline.
Even better, because everything is structured OSCAL data, the agent can do things that would be impossible with traditional documents. It can show you a timeline of how AC-2's implementation status has changed over the past six months. It can identify gaps in your evidence collection before an auditor finds them. It can automatically draft POA&M entries when scans detect issues. It can generate the exact report format your authorizing official prefers without anyone manually copying data between systems.
The continuous monitoring workflow becomes particularly elegant. Your security tools (AWS Config, Tenable, Qualys, whatever you're using) feed findings into OSCAL assessment-results documents. The MCP server processes these continuously, updating control status in real-time. Your compliance dashboard, powered by MCP UI Apps, shows you exactly which controls have new findings and what the risk impact is. When it's time for your monthly POA&M submission, the agent generates it directly from the structured data, in exactly the format FedRAMP requires.
This isn't theoretical. Organizations are already building these workflows, and the difference in efficiency is staggering.
The One-Prompt Control Mapping: Composing MCP Servers
Before we dive into building full UI applications, let me show you something that demonstrates the real power of the MCP ecosystem: server composition. One of the most tedious compliance tasks is creating control mapping matrices (those massive spreadsheets that show which of your system components satisfy which regulatory requirements). Traditionally, this involves copying control descriptions from PDFs, manually formatting Excel sheets, and ensuring consistency across hundreds of rows. It's the kind of work that takes days and introduces errors with every copy-paste operation.
With the OSCAL MCP server and the Excel MCP server working together, you can accomplish this entire workflow with a single natural language prompt. Let me show you what this looks like in practice.
Imagine your compliance team needs a spreadsheet mapping all FedRAMP High baseline controls to your system's implementation status. In the traditional workflow, someone would open the FedRAMP baseline document, start a new Excel file, and begin the painstaking process of transcribing 325 controls with their titles, families, implementation requirements, and enhancement details. They'd manually add columns for implementation status, responsible parties, and evidence locations. The whole process might take two or three days of focused work, and you'd still find formatting inconsistencies and transcription errors during review.
Setting Up the MCP Servers
First, you need to install both MCP servers. The process is straightforward if you're using Claude Code or another MCP-compatible client:
Installing the OSCAL MCP Server:
# Using Claude Code CLI
claude mcp add --transport stdio oscal -- uvx --from mcp-server-for-oscal@latest server
This installs the OSCAL MCP server using uvx (the Python package runner) and configures it to run via standard input/output transport. The server automatically has access to NIST's OSCAL catalogs, profiles, and schemas.
Installing the Excel MCP Server:
# Using Claude Code CLI
claude mcp add --transport stdio excel -- npx -y @negokaz/excel-mcp-server
This installs the Excel MCP server using Node.js's npx package runner. The server can read and write Excel files (.xlsx, .xlsm, .xltx, .xltm) in your local filesystem.
Restart Your MCP Client:
After adding both servers, restart Claude Code or your MCP client to load the new server configurations. You can verify they're loaded by checking available tools; you should see OSCAL-related tools (like get_oscal_schema, list_oscal_models) and Excel-related tools (like create_workbook, read_cells, write_cells).
The One-Prompt Workflow
Here's the same task with composed MCP servers:
Step 1: Make Your Request
You tell your AI agent: "Create an Excel spreadsheet with all FedRAMP High baseline controls. Include columns for control ID, title, family, baseline impact, description, implementation status, responsible role, and evidence location. Format it as a proper table with filters."
Step 2: OSCAL Server Queries the Control Catalog
The agent, with access to both servers, first queries the OSCAL server for the FedRAMP High profile. The OSCAL server returns structured JSON data containing all 325 controls with their properties, parameters, requirements, and relationships. The control descriptions come directly from the authoritative NIST catalog, eliminating any possibility of transcription errors.
Step 3: Agent Processes the OSCAL Data
The agent extracts the specific fields needed for your spreadsheet from the OSCAL response (control identifiers, titles, family groupings, baseline impact levels, descriptions, and any control enhancements). This data is structured consistently because it follows the OSCAL schema.
Step 4: Excel Server Creates the Workbook
The agent instructs the Excel server to create a new workbook file. It specifies the file location and initial workbook configuration based on your request.
Step 5: Excel Server Sets Up the Table Structure
The Excel server adds a worksheet and creates column headers matching your requirements: Control ID, Title, Family, Baseline Impact, Description, Implementation Status, Responsible Role, and Evidence Location. It formats these headers with bold text and applies AutoFilter to enable sorting and filtering.
Step 6: Excel Server Populates Control Data
In an efficient batch operation, the agent instructs the Excel server to populate each row with control data extracted from OSCAL. The Excel server handles all low-level spreadsheet mechanics cell formatting, data type specification, row heights, and column widths. If you requested color coding or conditional formatting, the server applies those styling rules based on implementation status values.
Step 7: Excel Server Finalizes Formatting
The Excel server formats the complete table applies borders, sets number formats for any calculated fields, protects cells that shouldn't be edited (like control descriptions), and ensures the table meets Excel's structured table specifications for proper filtering and sorting.
Step 8: Delivery
The entire process completes in seconds. You receive a professional, ready-to-use compliance tracking spreadsheet with all 325 FedRAMP High controls properly formatted and ready for your team to populate implementation status. The formatting is consistent because it's programmatically generated, and the control data is authoritative because it came directly from NIST's OSCAL repository.
Why This Matters: Regeneration and Cross-Framework Mapping
What makes this particularly powerful is the regeneration capability. Because this is driven by structured OSCAL data and programmatic Excel generation, you can recreate the spreadsheet whenever you need to. When FedRAMP updates their baseline, you don't manually merge changes into your spreadsheet you just run the same prompt again and get an updated version reflecting the latest requirements. When your implementation status changes, you update the OSCAL data in your system-security-plan and regenerate the tracking sheet with current information.
The OSCAL server also understands the relationships between different compliance frameworks. You can ask for a mapping that shows HIPAA Security Rule provisions in one column and their corresponding NIST 800-53 controls in adjacent columns. The OSCAL mapping-collection model contains these cross-framework relationships, and the agent can query them automatically.
This pattern works for any compliance framework with OSCAL representations. HIPAA Security Rule? Same workflow. CIS Critical Security Controls? Absolutely. StateRAMP, CMMC, TX-RAMP if there's an OSCAL catalog or profile for it, you can generate tracking spreadsheets instantly. The OSCAL community has already created catalogs for dozens of frameworks, and more are being added continuously.
You can take this further by combining additional MCP servers. Imagine adding a Git MCP server to the mix. Now your control mapping spreadsheet can be version controlled automatically. Every time you regenerate it with updated data, the agent commits it to your compliance repository with a meaningful commit message describing what changed. Your audit trail is built automatically.
Or consider adding a cloud provider MCP server for AWS, Azure, or GCP. The agent could query your actual infrastructure configuration, compare it against control requirements from OSCAL, and populate the implementation status column based on what it finds in your environment. Instead of manually claiming that AC-2 (Account Management) is implemented, the agent verifies your IAM policies, checks your SSO configuration, and confirms that the control is actually satisfied before marking it as implemented in the spreadsheet. Here's som
The Excel MCP server itself is quite capable. It handles not just basic data insertion but sophisticated formatting operations. You can specify border styles, cell fills, font properties, and number formatting. For compliance matrices, this means you can have properly formatted status indicators green cells for implemented controls, yellow for in-progress, red for gaps. You can apply currency or percentage formatting to cost or completion columns. You can set cell protection to prevent accidental modification of control descriptions while allowing status updates.
The server also supports formula insertion, which opens up interesting possibilities. Your compliance tracking sheet can include calculated fields percentage of controls implemented per family, weighted risk scores based on control failures, days until evidence expiration. These formulas update automatically as you modify the underlying data, giving you a living compliance dashboard in spreadsheet form.
For organizations still heavily dependent on Excel for compliance work and that's most organizations in government contracting this capability is transformative. You're not abandoning your existing workflows or forcing people to adopt entirely new tools. You're enhancing spreadsheet-based processes with automation backed by authoritative, structured compliance data.
What previously required days of manual work researching controls, formatting spreadsheets, ensuring consistency, updating as requirements change now happens in seconds with a single prompt. Your compliance team focuses on the substantive work of actually implementing and assessing controls rather than wrestling with document formatting and data entry. And because everything flows from structured OSCAL data, you maintain consistency and accuracy that manual processes simply can't match.
This is practical compliance automation. Just two MCP servers, an AI agent that can talk to both, and the power to transform compliance documentation workflows with simple requests. The fact that you can generate a complete, properly formatted control mapping matrix with a single prompt represents exactly the kind of efficiency gain that makes OSCAL adoption worthwhile.
Building Your First Compliance MCP UI App
Let's get practical. Building an MCP UI App for compliance involves three main layers: the OSCAL data layer, the MCP server layer that exposes tools and UI resources, and the actual UI components that render in the agent conversation.
Starting with your OSCAL data, you need component definitions that accurately describe your system's security controls. This is actually easier than it sounds if you already have some form of compliance documentation. Many organizations are using tools like IBM's Compliance Trestle or the GSA's OSCAL converters to transform existing SSPs into OSCAL format. If you're starting fresh, the NIST OSCAL content repository provides excellent templates and examples.
Your component definition should describe each significant part of your system your application tier, database layer, authentication service, logging infrastructure and specify which controls each component implements. Be specific about implementation details, not just claiming that a control is "satisfied" but explaining how it's satisfied. Include properties for implementation status, responsible roles, and any test procedures. This structured data becomes the source of truth that everything else builds on.
The MCP server implementation is where the intelligence lives. You're building a service that exposes both tools (for querying and manipulating OSCAL data) and resources (the UI templates). The tools handle operations like listing controls for a baseline, retrieving detailed implementation information, generating POA&M entries from findings, and updating control status. The resources define the HTML templates that render your compliance interfaces.
Here's what a practical MCP server structure might look like. You register multiple UI resources one for a high-level compliance dashboard, another for detailed control viewers, perhaps a third for POA&M management. Each resource is essentially a self-contained single-page application that communicates with the host via postMessage.
server.setRequestHandler('resources/list', async () => {
return {
resources: [
{
uri: 'ui://compliance-dashboard',
name: 'FedRAMP Compliance Dashboard',
description: 'Real-time visualization of control implementation status across all FedRAMP baseline requirements',
mimeType: 'text/html'
},
{
uri: 'ui://control-detail-viewer',
name: 'Control Implementation Detail Viewer',
description: 'Comprehensive view of individual control implementations with evidence artifacts and assessment history',
mimeType: 'text/html'
},
{
uri: 'ui://poam-manager',
name: 'Plan of Action and Milestones Manager',
description: 'Interactive interface for tracking and managing remediation activities',
mimeType: 'text/html'
}
]
};
});
The UI templates themselves need careful design. Remember that they're running in sandboxed iframes with limited access to the outside world. All data comes through postMessage, and all actions go back through the MCP JSON-RPC protocol. This constraint actually helps create clean architectures your UI becomes a pure view layer that requests data and emits intents, while the intelligence stays in the agent and MCP server.
A compliance dashboard might request initial data when it loads by posting a message to the parent frame. The message follows the JSON-RPC format, calling an MCP tool with appropriate parameters. The MCP server fetches the relevant OSCAL data, processes it, and returns it to the UI. The UI renders the visualization using modern web components and CSS that adapt to the host application's theme.
// UI component requests data on load
window.addEventListener('load', () => {
window.parent.postMessage({
jsonrpc: '2.0',
method: 'tools/call',
params: {
name: 'list_controls',
arguments: {
baseline: 'FedRAMP-HIGH',
status: 'all'
}
},
id: 'init-load-1'
}, '*');
});
// Handle responses from MCP server
window.addEventListener('message', (event) => {
if (event.data.id === 'init-load-1' && event.data.result) {
const controls = JSON.parse(event.data.result.content[0].text);
renderDashboard(controls);
}
});
The rendering logic can use modern web component libraries or simple vanilla JavaScript, depending on your preferences. The key is creating visualizations that make complex compliance data comprehensible at a glance while still allowing drill-down into details.
Consider a control status card that shows implementation state, evidence freshness, responsible parties, and any open findings. Color coding provides instant visual feedback green for fully implemented and verified, yellow for implemented but needing evidence updates, red for gaps or failures. Clicking the card emits an intent to view details, which the agent handles by displaying a more detailed UI resource or generating a natural language summary.
The design patterns that work well for compliance UIs tend toward progressive disclosure. Don't try to show everything at once. Start with a high-level overview maybe percentage complete by control family, a risk heatmap, or a timeline of recent assessment activities. Let users drill into specific families, then individual controls, then implementation details and evidence. This layered approach matches how people actually navigate compliance information.
Design Patterns for Visual Compliance
Several patterns have emerged as particularly effective for compliance MCP UI Apps, and it's worth understanding why they work.
The progressive disclosure pattern I just mentioned addresses a fundamental problem with compliance documentation: the sheer volume of information. A FedRAMP High SSP documents 325 controls, each with multiple implementation statements, control enhancements, and evidence references. Presenting all of this simultaneously is overwhelming. But users need different levels of detail depending on their role and current task.
An executive reviewing compliance posture wants a dashboard showing percentage complete, high-risk gaps, and overall trend. A security engineer implementing controls needs detailed technical specifications, evidence requirements, and test procedures. An auditor needs to trace from control requirement through implementation to evidence artifacts. Progressive disclosure lets the same underlying OSCAL data serve all these use cases by controlling what's visible at each navigation level.
The evidence automation pattern tackles another persistent pain point. Compliance requires proof, and gathering evidence is traditionally manual and error-prone. Someone exports user lists from the IAM system, takes screenshots of security group configurations, downloads vulnerability scan reports, and attaches them all to the SSP. By the time an auditor reviews the document, half the evidence is outdated.
MCP UI Apps can integrate evidence collection directly into the compliance workflow. When displaying a control implementation, the UI queries the relevant systems automatically. For AC-2 (Account Management), it might call AWS IAM APIs to verify current account provisioning policies, query your identity provider for SSO configurations, and fetch audit logs showing account lifecycle events. This evidence appears in the UI with timestamps and source references. If evidence is stale or missing, the UI surfaces this immediately rather than waiting for an auditor to discover the gap.
// Evidence collector pattern
async function collectEvidence(controlId: string) {
const evidenceSpecs = {
'AC-2': [
{
source: 'aws-iam',
check: 'account-provisioning-policy',
api: 'getAccountPasswordPolicy'
},
{
source: 'okta',
check: 'sso-configuration',
api: 'listIdpSettings'
},
{
source: 'cloudwatch',
check: 'account-activity-logs',
query: 'filterPattern:"account created OR account deleted"'
}
]
};
const specs = evidenceSpecs[controlId];
const evidence = await Promise.all(
specs.map(spec => fetchFromSource(spec))
);
return {
control_id: controlId,
evidence_items: evidence.map(e => ({
source: e.source,
collected_at: new Date().toISOString(),
status: e.status,
artifact: e.data
})),
completeness: calculateCompleteness(evidence)
};
}
The inheritance visualization pattern addresses a complexity specific to cloud compliance. When you run a system on AWS, Azure, or GCP, you inherit certain security controls from the cloud provider. Physical security controls, for example, are entirely the provider's responsibility. Network infrastructure controls are shared between you and the provider. Application-level controls are entirely your responsibility. Understanding this responsibility matrix is critical for accurate compliance documentation.
Traditional SSPs handle this with tables showing "Customer," "Provider," or "Shared" for each control. It's functional but not intuitive. A visual representation makes the relationships immediately clear. Imagine a control card that uses color coding to show responsibility blue background for inherited controls where you just need to verify the provider's certification, split color for shared controls where you need to coordinate with provider capabilities, and orange for controls you fully own. Clicking a shared control shows exactly which aspects are your responsibility versus the provider's.
This becomes especially powerful when dealing with control inheritance from multiple sources. Maybe you're inheriting physical controls from AWS, identity controls from Okta, and network controls from Cloudflare. A dependency graph visualization can show how these inherited controls flow down to your application components, making it clear where your compliance posture depends on third-party certifications.
Key Takeaways
If you take away nothing else from this discussion, understand that we're witnessing a fundamental shift in compliance workflows. For decades, compliance has been a documentation problem how do we describe our security controls in ways that satisfy auditors? We've thrown more people at the problem, created templates and frameworks, built workflow tools for managing documents. But we've been optimizing the wrong thing.
Compliance should be a data problem. We should be capturing structured information about our systems, their components, how those components implement security controls, and the evidence that proves those implementations work. This data should be continuously updated as systems evolve, continuously assessed to verify correctness, and continuously available for any stakeholder who needs it.
MCP UI Apps provide the human interface layer that makes this data-centric approach practical. They transform raw OSCAL data into visual, interactive experiences that match how people actually think about compliance. They let AI agents become intelligent assistants that surface the right information at the right time in the right format, rather than forcing users to search through documents or construct complex queries.
OSCAL provides the standardization that makes automation possible. When compliance data follows a common schema, tools can interoperate. Your evidence collection tools can feed your assessment tools, which can update your SSP automatically, which can drive your compliance dashboards. Breaking down these silos has been impossible when every organization uses different document formats and structures.
The security implications of this shift are worth emphasizing. Better compliance tooling doesn't just make audits less painful it makes systems more secure. When compliance data stays synchronized with actual system state, you catch drift immediately. When evidence collection is automated, you can't inadvertently document a security control that isn't actually functioning. When assessments run continuously, you detect failures quickly rather than discovering them months later during an audit.
Getting Started
If this vision resonates with you, the good news is that you can start building today. The MCP SDK is open source and well documented. NIST provides extensive OSCAL content including example catalogs, profiles, component definitions, and SSPs. The community has built numerous OSCAL tools and libraries in every major programming language.
Start small. Pick a single compliance framework you're dealing with maybe HIPAA if you're in healthcare, or SOC 2 if you're a SaaS provider. Convert one component's control implementations to OSCAL format. Build a simple MCP server that can query this data. Create a basic UI resource that visualizes the status of one control family. Get the cycle working, then expand.
The OSCAL Club and broader OSCAL community are remarkably helpful. There are quarterly NIST OSCAL workshops where adopters share experiences and challenges. The GitHub repositories for various OSCAL tools have active discussions. The community is small enough that you can get direct help from people doing similar work, but large enough that most problems have been solved by someone already.
For MCP-specific guidance, the Model Context Protocol documentation includes comprehensive examples of UI Apps. The Discord community is active with developers building all sorts of MCP servers. As adoption grows, we'll see more examples of compliance-specific implementations, but the patterns are already well established.
Resources that will help you get started include the NIST OSCAL content repository with reference implementations, the GSA FedRAMP automation repository with OSCAL baselines and conversion tools, the IBM Compliance Trestle project for OSCAL workflow automation, and the various OSCAL libraries listed in the Awesome OSCAL community collection. The MCP SDK documentation covers everything from basic server implementation to advanced UI App patterns.
Final Thoughts
Compliance will never be completely painless. It represents real security requirements that deserve serious attention. But the current state of compliance documentation and assessment is unnecessarily painful, artificially separated from the systems it's meant to secure, and doesn't scale to modern cloud operations.
MCP UI Apps and OSCAL together offer a path forward. A path where compliance becomes a continuous, data-driven process integrated directly into how we build and operate systems. Where AI agents can help us navigate complex regulatory requirements and automatically handle tedious documentation tasks. Where visual, interactive interfaces make compliance information accessible to everyone who needs it, not just specialists who've memorized the NIST 800-53 control structure.
The technology is ready. The standards exist. The tools are being built. What's needed now is adoption organizations willing to invest in transforming their compliance infrastructure, developers willing to build OSCAL-native tools, and a community willing to share lessons learned.
The compliance revolution won't be televised, but it will be visualized, automated, and powered by the same AI and cloud technologies that created the need for better compliance in the first place. The question isn't whether this transformation will happen it's whether your organization will lead it or follow it.
Start building. The future of compliance is visual, interactive, and intelligent. And it's being built right now.