> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/using-platform/seal-ui-tour.md). # The Seal UI tour The Seal UI exposes a set of top-level pages, most reachable from the left navigation, with the Notification Center reachable from the bell icon in the top bar. Each page owns a distinct slice of the platform's functionality, and most have a dedicated chapter elsewhere in these docs that goes deeper. This page is a one-screen orientation: what each page is for, who typically uses it, and where to read the full chapter.
The Seal UI with the left navigation showing the top-level entries (Seal Agent, Dashboard, Protection, Projects, Repository, Reports, Settings) and the Notification Center bell in the top bar

The Seal UI's left navigation and the top-bar Notification Center.

## The pages ### Seal Agent The chatbot interface to the Seal AI Agent. You describe what you want — "tell me about CVE-2024-12345 in our codebase", "draft a Sealing Rule for `lodash`", "summarize this week's vulnerable packages" — and the agent reasons over your tenant's data, calls platform APIs, and replies in-thread. Conversations are saved and archived in the sidebar of the page itself. The Agent is read-only by default but can also act on the tenant when you ask it to: creating a Sealing Rule, marking a Scanner Exclusion, triggering Generate fix, drafting a config snippet for your CI. Write actions ask for explicit confirmation in-thread before they run. The Seal Agent entry is only visible to customers who have enabled it in their tenant preferences. Typical audience: anyone who would rather ask a question in natural language than navigate to a page. Often the first page a security analyst opens at the start of a triage session. Full chapter: [The Seal AI Agent](/using-platform/seal-ai-agent.md). ### Dashboard The tenant-wide aggregate view: counts of vulnerable and sealed packages broken down by severity, top vulnerable projects, time-savings tiles, and a vulnerable-packages-over-time chart. Refreshed once a day. The right page to open when you want a one-screen read on the tenant's posture. Typical audience: security leaders and security analysts who want the executive snapshot. Developers and DevOps engineers usually skip past it to the Protection page. Full chapter: [The Dashboard](/discovering/dashboard.md). ### Protection The triage page. Four tabs cover every package Seal has seen in your tenant: vulnerable, sealed, the Sealing Rules driving the replacements, and any Scanner Exclusions in effect. This is where day-to-day work happens — review what's vulnerable, decide what to seal, watch the state badges roll forward as builds run. Typical audience: security analysts and security engineers doing the day-to-day triage; developers checking what's outstanding on a project they own. Full chapter: [The Protection page](/discovering/protection-page.md). ### Projects The list of Seal Projects in your tenant. Each row is one Seal Project with its mode, last-seen timestamp, and connection status. The page is the entry point for adding a new project (manually or by importing from a connected source-control integration) and for the per-project settings drawer (renaming, archiving, deletion). Typical audience: DevOps and platform engineers managing the project inventory; security engineers when they need to see the per-project view in isolation rather than the aggregate Protection-page view. Documented under [Creating a Seal Project](/getting-started/creating-a-seal-project.md) and the per-mode connector how-tos under [Package discovery mode](/discovering/package-discovery-mode.md). ### Repository The public catalog of sealed packages. Anyone with the URL can browse — no Seal account needed — to look up whether a specific `package@version` has a sealed counterpart, see what vulnerabilities the sealed version remediates, view the code diff, and share a public link to a specific diff. The same page also hosts the **Free assessment** flow that accepts a manifest upload and reports back coverage. Typical audience: prospects and external auditors who want to verify Seal's coverage without an account; customers when they need a shareable link to a code diff for an auditor or downstream consumer. Full chapter: [The Repository page](/discovering/repository-page.md). ### Reports The report editor. Three report types are available — vulnerable packages, sealed packages, and ROI — each with a configurable scope (date range, projects, severities) and a downloadable output. A **Reports history** sub-page lists previously generated reports for re-download. Typical audience: security leaders preparing periodic posture reports for executives or auditors. Full chapter: [Reports Manager](/using-platform/reports-manager.md). ### Settings The administrative page for the tenant. Pinned to the bottom of the left navigation. Its sidebar splits into two groups: * **Tenant** — Preferences, User permissions, Integrations, CLI integration, Tokens, Usage, Admin portal (Admin role only). * **User** — Notifications (your personal email-notification preferences). Most Tenant items are gated by the Admin role; the User-section Notifications item is per-user. Typical audience: tenant administrators handling user lifecycle, SSO setup, integrations, and credential management; every user for their own Notifications preferences. Documented across [Managing users, roles & SSO](/getting-started/users-and-sso.md), [Managing tokens](/getting-started/tokens.md), and the per-integration setup chapters. ### Notification Center Reached from the bell icon in the top bar rather than from the left navigation. It shows the list of in-app notifications delivered to your user. Email notifications are a separate channel and do not mirror what appears in the Notification Center. They are configured per user under **Settings → User → Notifications**. Full chapter: the Notification Center chapter later in this section. ## How the pages relate The Protection page is where decisions get made — review the vulnerable list, set Sealing Rules, mark Scanner Exclusions. The Dashboard aggregates the outcomes of those decisions over time. The Projects page tracks what is being protected at all. The Repository page is the catalog of every sealed package Seal has published. Settings and the Notification Center configure who can do what and how Seal reaches you. Reports and the Seal Agent are alternative ways into the same data — Reports for periodic export, the Agent for both ad-hoc questions in natural language and for driving the same actions you'd otherwise do by hand (creating Sealing Rules, marking exclusions, triggering Generate fix). Most day-to-day operation happens on the Protection page. The other pages are visited as needed. ## Related * [The Dashboard](/discovering/dashboard.md) * [The Protection page](/discovering/protection-page.md) * [The Repository page](/discovering/repository-page.md) * [Working with the platform](/using-platform/working-with-the-platform.md): the operating-rhythm overview that this tour supports.