Use Secureframe with Sazabi: tie failing compliance tests to real systems

Last verified on Nov 8, 2026.

Compliance tooling and production telemetry usually live apart. A log search tells you a storage bucket policy changed at 02

Sazabi is AI-native observability and security. Connect Secureframe and the Sazabi agent can read that compliance record next to the logs, so a security finding and its audit impact can be checked in the same thread.

What the Sazabi agent can do with Secureframe

Secureframe hosts the MCP server and the connection uses OAuth. The Sazabi connector page lists the abilities:

• Query compliance frameworks and control status.
• Run and inspect automated compliance tests and remediation steps.
• Audit vendor security posture, questionnaires and risk tiers.
• Monitor personnel onboarding, training, MFA and device compliance.
• Track manual evidence, tasks and System Security Plan details.

Secureframe's MCP docs show how many tools sit behind that: 112 across 41 categories, wrapping its REST API. The ones an engineer reaches for first are read tools:

• list_tests and get_test for automated tests.
• list_cloud_resources, list_repositories and list_devices for the assets tests run against.
• list_integration_connections to see which systems Secureframe pulls from.
• list_controls, list_frameworks and list_framework_requirements for the audit side.
• list_risks and list_third_party_risk_management_vendors for the risk register and vendors.

The server also has write tools such as update_test and update_cloud_resource. Every request runs as the signed-in Secureframe user, in the company they chose, with that user's permissions. Sazabi's read-only toggle keeps the connection to read-only tools.

Questions it answers

• Which automated tests are failing right now, and which assets do they cover?
• Is the cloud resource named in this log finding tracked in Secureframe?
• Which controls does a failing test belong to?
• Which repositories or devices are in the inventory for this environment?
• Which risks and vendors are open that relate to the service under investigation?

A worked example: a changed security group and the audit record

Your logs show a security group in the production account opened to a wider range at 02

Using Secureframe, list the failing automated tests and the cloud
resources they relate to. Is sg-0a1b2c3d4e5f60718 in the inventory? Which
control does any related test map to? Then compare against the 02:10
change in the CloudTrail logs.

The agent calls list_tests and reads the failing ones. It calls list_cloud_resources and looks for the security group by identifier, then reads get_test for any matching test to see the details. list_controls gives the control each test supports. From your logs it takes the CloudTrail entry for the change.

The answer separates two facts that are easy to blur. One is the change itself, which comes from your logs. The other is its compliance record: whether Secureframe sees the resource, which test fails and which control it affects. If you want the result recorded as a task or comment, that needs a write-enabled connection, so keep it off when you only want to look.

Connecting the right region

Secureframe runs separate US and UK deployments with different MCP URLs, and the Sazabi connection asks for the region up front. A wrong choice shows up as no tools discovered, so reconnect with the other region if that happens. Sign-in follows your normal Secureframe login, including SSO and multi-factor steps.

How it fits with other integrations

The compliance record is most useful beside the systems it describes. Cloud audit logs from AWS show who changed a resource, and the edge view from Cloudflare shows what traffic reached it. Both live in cloud platforms, and the broader security category covers more sources. The integrations page lists everything, and pricing covers Sazabi plans.