For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
This guide is part of the User Guides collection. It covers the Inspect screens. For what the module is and how internal and third-party risk share one model, see Internal control monitoring and Agentic Inspect. For the control sets it evaluates, see the Control Set library.
Inspect is an optional module. If you do not see Inspect in the left navigation, ask your Coverbase representative to turn it on.
Where it lives
Inspect in the left navigation opens five tabs: Overview, Inspections, Probes, Applications and Accounts. Configuration at the right of the tab strip opens Configuration → Inspect, where identity providers are connected. Schedules is a button on the Inspections tab, not a tab of its own.
The Overview tab: application tiles, posture, what needs you, and the latest inspections.
Connecting an application
Inspect needs two things from an application: a way to sign in, and a Platform so it knows which documentation and API catalog to plan from. There are two routes in.- Through an identity provider
- Directly
Go to Configuration → Inspect. Each provider card reads Connected, Needs verification, Connection error or Not connected, and shows how many applications are added to Inspect against how many are available in the provider.
1
Okta
Connect Okta walks through App details (your Okta org URL and the Client ID of an API Services app you create for Coverbase Inspect), Configure the Okta connection (add the Coverbase JWKS URL as the app’s public key, grant a Read-only Administrator role for inventory, and grant the Organization Administrator and Application Administrator roles that let Coverbase create the inspection identity), then Choose applications to add.Run Sync from Okta to pull users, applications and assignments. When you add applications, tick the approval box: Coverbase provisions a dedicated read-only inspection identity in Okta and assigns it only the applications you selected. Afterwards, Sign in to Okta under Okta sign-in so the identity has a live session. Its status reads Not signed in, Sign-in started, Signed in, Sign-in expired or Sign-in failed.
2
Microsoft Entra
Connect Microsoft Entra follows the same shape: App details for an application you register in your tenant, Configure the Entra connection to verify the Graph permissions, Sync and select applications, then Prepare applications for inspection. An Entra application without SAML or OIDC single sign-on shows as Blocked in the applications list, because Inspect has no way to sign in to it.
3
Google OAuth
Google OAuth stores the Google account email and password Inspect signs in with, plus an optional TOTP secret. Applications that use Google sign-in are added directly (next tab) and pick up these credentials. Run test inspection checks that the sign-in works before you rely on it.
The Applications tab: one row per application, with its source, sign-in method, status and when it was last inspected.
Reading the applications list
Search, filter by source or status, and select rows to Add, Archive, Unarchive or Find vendor matches in bulk. The last one links each application to the vendor record it belongs to, so internal and third-party evidence sit on the same vendor.
Click a row to open the drawer. Summary holds the login URL, status and a Vendor link. Users lists the assigned users, with Admin where the provider profile names an admin role. Factors manages verification factors for the inspection identity. API Settings holds the API origin, credentials and request parameters that API-based evidence needs; identity provider access does not establish API access, so an application can be signed in and still need this tab filled in. Inspection readiness at the foot of the drawer links to Review readiness, which opens the inspection setup with this application selected.
Running an inspection
The New inspection panel: application, control set and purpose at the top, then each control's plan readiness.
1
Choose what to inspect
On Inspections, click New Inspection. Pick an Application and a Control set. If the application has no control sets yet, Add Starter Controls forks a starter set so there is something to run. The full set of internal templates lives in the Internal Controls Library, reached from Controls → Internal Controls → Internal Controls Library; a forked template is an ordinary control set you can edit.
2
Choose a purpose
Evaluate needs a scale with an active level on the control set. Without one the launch is refused with None of the selected controls can be evaluated. Apply a scale with an active level, or choose Explore.
3
Decide on browser evidence
Browser evidence lets Inspect sign in and read pages when the documentation points there. Leave it off and only API methods run; the panel tells you how many controls that holds back (Allowing browser evidence releases N controls).
4
Get the plans ready
Every control needs a plan: what evidence to collect and how. The list groups controls into Ready, Preparing, Not prepared and Blocked. Click Prepare Plans for the unprepared ones and wait; a blocker names what is missing (no platform, API origin or credentials not configured, plan preparation failed). Recheck readiness re-reads the configuration after you fix something.
5
Launch
Launch Inspection starts everything that is ready. If only some controls are ready the button says so: X of Y controls will run. The rest will be recorded as not planned. Those controls end as Not planned rather than silently dropped.
Reading an inspection
The Inspections list shows Application, Initiated, Status, Purpose, Control set, Controls finished, Outcomes, Score, Findings and Channel (API or Browser). The default view, Inspection runs, hides probe runs; All inspections includes them. Open a row to read it.Statuses
An inspection carries one status; each control inside it carries its own.Inside a control
Click a control to open its workspace. A control from a framework-derived set, such as CIS Controls v8.1 SaaS Baseline, shows its framework references as badges under its expectation: the CIS safeguard it derives from and the NIST SP 800-53 controls mapped to it. Evaluation shows the level the control landed on and the Justification written from the evidence; This control has not been evaluated yet and This control could not be fully evaluated are the two states short of a verdict. Observations lists each evidence key with its records, where it was Collected from, the screenshot captures, and Watch replay for the browser session. Activity is the event log. Each observation carries a status, and an absent one is reported rather than skipped:
Row actions: Retry on a failed or blocked control, Rerun on a finished one, Rerun with updated control after you edit the control (a new plan is prepared first), and Cancel. Select several rows to retry, rerun or cancel together. At the top of the page, Actions → Archive removes the inspection from the list, Cancel Inspection stops a running one, and Create schedule turns this application and control set into a monthly run.
Drift between runs
A Drift inspection collects the same evidence as its reference and reports what moved. The header links to View reference inspection. Each control lands in one state:
The comparison panel shows Reference beside This inspection, marks each record Changed, Added or Removed, and hides unchanged records behind Show N unchanged records. If a requirement does not say which fields identify a record, an edited record appears as one removed and one added; the panel says so. Editing a control changes what it collects, which is why Can’t compare appears after a control edit: take a fresh Evaluate run as the new baseline.
From an issue to a finding
Only Evaluate inspections produce evaluations. On a control whose evaluation raised an issue, Create Finding in the Evaluation panel creates a finding with the control’s expectation as its title and the evaluation attached as its source. Clicking again returns the same finding rather than a duplicate; the button then reads View Finding. Coverbase drafts remediation guidance for the finding from the evidence the run collected, so each step can be checked against an observation. From there it is an ordinary finding. On the Findings page, filter Source by Inspect evaluation to see only these. Assign an owner and due date, route it with the same workflows as third-party findings (see Workflow templates), and it counts in the same dashboards (see the Dashboard library). Overdue internal findings surface back on the Inspect Overview under What needs you. The Risk module can also take Inspect as a signal source, reading evaluations marked as issues on internal control sets.Plans and plan versions
A plan is what Inspect prepared for one control on one platform: each Requirement with its question, Comparison focus, Observation contract (what fields to record and how many records to expect) and Evidence methods (Browser, REST, GraphQL, Query or Metadata), plus the Documented destination, What to record and a Suggested route. Reach it with Review Plan in the inspection setup or View plan from a control. Plans are immutable. Edit plan does not change the plan that ran; Publish new version creates the next version and marks the old one superseded. Inspections already running keep the version they started with.
Check changes validates before you publish. A refusal names what was wrong: an empty field, an uneditable part of the plan, a route hint with characters other than letters, numbers, hyphens and underscores, or This plan changed while you were editing, which means someone else published first; reload and reapply.
Two rules about whose plan it is:
- Coverbase maintains this plan. Editing it saves your organization’s own copy. A public plan stays as it is for everyone else, and your copy starts at version 1. From then on your organization sees its own plan, not Coverbase’s later improvements to the public one.
- To edit this Coverbase plan, open it from one of your organization’s controls. Editing needs a control in your organization to hang the copy on.
Probes
An inspection evaluates a control set once. A probe answers one small question on a cadence: is MFA still enforced, did the nightly export land, does this record show the status we expect. Probes sit on their own tab and their runs appear in Inspections under the All inspections view.1
Describe it
On Probes, click New probe. Give it a Name, pick an Application, and answer What should this probe observe? in plain language, naming the view or record and the facts to collect. Click Prepare probe.
2
Review the procedure
Inspect turns the description into Checkpoints that run in order on one browser journey. Each checkpoint lists the Evidence to Collect, its Collection method (Browser or API), and an optional Expectation: a Field, a Comparison (Equals, Greater than, At least, Less than, At most, Is recorded), an Expected value, and whether it Applies To All records or Any record. A checkpoint with no expectation reads Data collection only and contributes no verdict. On Failure decides whether the run should Continue to next checkpoint or Stop remaining checkpoints. Reorder checkpoints, or click Prepare a new procedure to start over.
3
Run it once
Save and run (or Save probe, then Run now) executes the procedure once so you can check each checkpoint before anything repeats. A probe that has not been run shows In preparation.
4
Enable it
Choose a Frequency (Every 15 minutes, Every hour, Every 6 hours or Every day) and click Enable probe. Pause keeps the run history and stops scheduled runs.
Schedules
A schedule reruns an application and control set on a calendar day every month, with no one launching it. Open Inspections → Schedules, then New schedule: choose the Application, Control set, Purpose, whether to Allow browser evidence, and the Day of month. Create schedule on a finished inspection pre-fills the same dialog. A Drift schedule compares each run against the latest completed inspection of that application that ran the same control set, so run one before its first scheduled date. Each row shows Cadence (Monthly on the 15th), Next run, Last run and a Status of Active or Paused. Actions offers Edit schedule, Pause, Resume and Stop repeating; the last one keeps past runs in the inspections list and runs nothing further. Before each run Inspect checks sign-in and plan readiness. A run that cannot start is recorded as a missed check and the next occurrence still goes ahead. The inspection page names the cause:A monthly schedule that outlives its application keeps running until you pause or stop it. Archiving the application does not stop the schedule.
The AI Agents tab
Inspect › AI Agents gathers every AI agent, copilot or bot that an inspection found inside your applications, what each may do, and how each application and each vendor authorises agent actions at runtime. It reads the inspections and assessments you have already run; nothing on it is entered by hand. Five tiles lead: agents discovered, applications covered, agents with unattended write authority, applications with no kill switch, and vendors assessed. Each tile opens the view that explains it.1
Inspect an application for agents
Click Inspect for agents (or Inspect on a row that reads Never). The inspection setup opens with the AI Agents, Copilots & Autonomous Actions control set selected; pick the application and launch an Evaluate run. When it finishes, the application’s row fills in.
2
Read the Applications view
One row per connected application. The four posture cells follow the control set’s sections: Inventory, Authority, Attribution and Runtime authorization. Each reads Met, a count of issues, or Not inspected. A section whose every evaluated control failed reads red rather than amber. Drift reads Changed when the latest Drift run on the agents set found a difference. Clicking a row opens the application’s drawer.
3
Read the Agents view
One row per agent per application: its name and the application’s own identifier, owner, status, the identity it runs as (an administrator identity is marked red), the actions the console lists for it, who can reach it, and when an inspection last saw it. Nothing is inferred from an agent’s name: a chip says the agent can send email because the admin console said so.
4
Open an agent
The drawer shows what the agent may do, who runs and owns it, then Runtime authorization at <application>: the five checks a reviewer asks about, each with the inspection’s one-line judgment. Per-action policy on parameters, Task-scoped credentials, Delegating person on each action and Central policy across agents come from the template’s Runtime Authorization section; Kill switch from its Attribution & Reversal section. Create finding on a failing check raises a finding on that control, the same flow as the inspection’s own evaluation row. Evidence names the admin page the inventory was read from and the inspection it came from. The footer opens the inspection or the schedules page to watch the application for drift.
5
Read the Vendors view
The vendors whose agents act on your data. A vendor assessed with the AI Agent Runtime Authorization template carries four posture cells, Delegation, Runtime authorization, Credentials and Audit & stop, read from the assessment’s evaluations, and the date it completed. A vendor whose applications hold agents but that has no such assessment reads Not assessed with an Assess action that opens the vendor. Coverbase’s own agents are recorded on the Agent Ledger, linked below the table.
Agents are read from the inventory control’s records, so an application whose inspection plan lists agents under its own field names still appears: the tab reads the name, identifier, status, owner, actions, identity and audience fields under their common synonyms, and matches the authority controls’ records to the inventory by identifier or name. A record that names neither is not shown.
The Accounts directory
Accounts is what the provider syncs and the inspections observe, joined into one directory: a person or service identity, the application accounts that belong to it, and the evidence attributed to each account. It fills after the first Okta or Entra sync (Accounts appear once the sync finishes) and refreshes after every inspection. Built-in views: Accounts & evidence (the default: identities with at least one account), All identities, Guests, Admin observed, Observed evidence and Needs attribution. Save your own on top of any of them. Expand an identity to see its Application accounts. Each account states how it was tied to the identity:
Admin observed means an attributed observation once showed admin privileges on that account. It is historical, not a claim about current access. Admin privilege hint is weaker still: the provider’s assignment profile names an admin role, and no inspection has verified the application honors it. Latest observed admin state reads the most recent record: Admin, Not admin, or Unknown when the record carried no privilege attributes.
Rebuild attribution re-derives every account link from the current provider inventory and observations. Use it after changing an application’s platform or when the page says accounts need review.
Who can do what
Inspect is switched on per organization. Within it, access follows the integration permission described in Permissions and roles:Notifications
Inspect sends three emails to the person who started an inspection, or, for a scheduled run, to the schedule’s owner. Each is on by default and can be turned off under the Inspect category in your notification settings (see Email notifications).
Alerts from one inspection are gathered into a single email every few minutes rather than sent one per control, and Open inspection takes you to the page. Findings created from inspections follow the ordinary finding notifications.
Run Inspect from MCP or the API
You can connect applications, run inspections, read results and keep schedules from an MCP client or with an API key, as well as in the dashboard. An MCP client reads withquery_platform(kind=...) (inspect_targets, inspect_inspections, inspect_inspection_detail, inspect_schedules, inspect_plan, inspect_summary). It writes with mutate(entity="inspect_target", action=...), mutate(entity="inspect_plan", action=...), mutate(entity="inspect_inspection", action=...), mutate(entity="inspect_run", action=...) and mutate(entity="inspect_schedule", action=...).
The API routes sit under /v1/inspect-applications, /v1/inspect-plans, /v1/inspections and /v1/inspect-schedules. See Start an inspection.
Before an MCP client sends a write, it shows you the change and waits for you to confirm it. The MCP tool reference lists every field.
You can also run probes, read the identity directory and its credentials, follow Okta and Entra connections, sign a session in again and raise an evaluation as a Finding. MCP reads them with kinds such as inspect_probes, inspect_identity_detail, inspect_credentials, okta_inspection_identity and entra_inspection_identity, and writes with mutate(entity="inspect_probe", action="set_automation"), mutate(entity="inspect_auth_context", action="bootstrap") and mutate(entity="inspect_evaluation", action="create_finding"). The API routes sit under /v1/inspect-probes, /v1/inspect-identities, /v1/okta-integration and /v1/entra-integration. See Run probes.
Work that needs a browser session, the planning documents or a stored credential runs through the API, not MCP: drafting, saving and previewing probes, starting inspections, editing plans, and syncing, verifying or provisioning Okta and Entra. MCP says which API route to use.
An API key cannot archive, restore or delete an application, archive or restore inspections, stop a schedule, disconnect Okta, provision or deprovision an Okta or Entra inspection identity, or decide an access removal request. A signed-in user does those. Only an organization admin can sync, verify or provision Okta and Entra, or rebuild the identity inventory.
Troubleshooting
Related
Internal control monitoring
What the module is for, and how internal and third-party risk share one model.
Control Set library
The internal control sets Inspect evaluates against, with counts and sources.
Findings Manager
Where a finding created from an inspection goes next.
Permissions and roles
The integration and finding permissions this guide refers to.