> 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-ai-agent.md). # The Seal AI Agent The Seal AI Agent is a chatbot you talk to inside the Seal UI. You describe what you want — find a vulnerability, draft a Sealing Rule, get a CLI snippet for your CI — and the Agent reasons over your tenant's data, calls into the platform on your behalf, and answers in-thread. It is the conversational entry point to the Seal Platform for customers who would rather ask a question than navigate to a page. The Seal AI Agent is one of two Seal Platform features in the AI family. The other is the **Seal Engineer**, which is a different feature: where the AI Agent is a chatbot you talk to, the Seal Engineer runs scheduled automated flows and posts results to a Slack channel. The two are not interchangeable. The AI Agent does not connect to Slack; the Seal Engineer is documented in the next chapter. The Seal AI Agent and the Seal Engineer together make up the AI side of the Seal Platform. Both are off by default and only available to tenants that have explicitly enabled AI features in their settings. Customers who do not want AI features have no AI running on their data or their tenant. Once enabled, the Seal AI Agent is reached from the **Seal Agent** entry in the left navigation of the Seal UI. ## What the Agent does The Agent has read access to your tenant's data — your Seal Projects, the Vulnerable packages tab, the Sealed packages tab, your Sealing Rules, your Scanner Exclusions, your Repository-page sealed-package catalog. You can ask it questions about any of that and get a synthesized answer in-thread. The Agent can also take action on the tenant when asked: create or delete a Sealing Rule, trigger Generate fix, integrate the Seal CLI into your CI/CD by opening a pull request against your repository, and similar. Read queries run automatically; **write actions require explicit confirmation in-thread** before they execute. The Agent presents the proposed action as a card with **Approve** and **Deny** buttons; nothing changes in the platform until you approve. ## Querying your security posture The most common use is asking questions about what is currently true in your tenant. The Agent answers from the live data, not from training or assumptions. Example prompts that work well: * "What are the open critical vulnerabilities across all my projects?" * "Which packages are currently in `Generate available` state for project `api-server`?" * "Show me every Sealing Rule that targets `ejs`." * "How many vulnerabilities have I sealed in the last quarter?" * "Is there a sealed version of `lodash@4.17.20`?" The Agent picks the right operations to run against your tenant and summarizes the answer in plain language. If the answer is a list, it usually formats it as a table; if it is a count or a yes/no, it answers directly with a short explanation. For follow-up depth, ask. The Agent's working memory in a conversation lets it keep building on what it has retrieved: ask for the list, then ask the Agent to filter or sort or explain a specific row, and it works against the result it just produced. ## Creating and deleting Sealing Rules through the Agent
Seal AI Agent chat thread showing a Sealing Rule confirmation card with Approve and Deny buttons

The Agent presents a confirmation card before any write action.

You can ask the Agent to seal a package or create a tenant-wide rule directly, without navigating to the Protection page. Example prompts: * "Seal `ejs@2.7.4` in project `api-server`." * "Create a rule to seal every vulnerable package in all projects." (the UI-driven equivalent of the Automatic Remediation pattern; see [Sealing Rules — Use cases](/using-platform/sealing-rules.md#use-cases)) * "Pin `commons-text@1.10.0` to `1.10.0-sp1` tenant-wide." * "Delete the Sealing Rule for `lodash` in project `api-server`." The Agent translates the request into the matching rule shape (project scope, package target, substitute version) and presents a confirmation card showing what it is about to do. Review the card; click **Approve** to commit, **Deny** to cancel. Created rules appear on the [Sealing rules tab](/discovering/protection-page/sealing-rules-tab.md) as if you had created them through the UI form; deletions remove them. Editing an existing rule in place is not currently an Agent operation. To change a rule, either edit it on the Sealing rules tab, or ask the Agent to delete the existing rule and create the new one. ## Getting integration help from the Agent The Agent has knowledge of the Seal CLI's setup patterns and can help in two distinct ways. For general questions, the Agent produces ready-to-paste configuration snippets annotated with what each part does and a pointer to the relevant setup chapter: * "Give me a GitHub Actions step that runs `seal fix` after my `npm ci`." * "Show me a `Dockerfile` that runs the Seal CLI before the build." * "What `SEAL_PROJECT` value should I use for a multi-repo monorepo?" For repositories connected to the platform through the Seal GitHub App, the Agent can do the integration directly: ask it to integrate the Seal CLI into a repository, and the Agent inspects the build configuration, decides where the CLI step belongs (the right place in your `Dockerfile`, the right step in your GitHub Actions workflow, and so on), drafts the change, and opens a pull request against your repository for review. You read the PR, request changes if needed, and merge when ready. The Agent does not push directly; the change still goes through your normal review process. If no GitHub connection is in place when the Agent decides one is needed, the Agent shows a link in-thread that opens GitHub in the context of granting permissions to the Seal GitHub App. Following the link completes the install; from there the Agent's GitHub-context capabilities are available. You can also set up the connection in advance under [Settings → Integrations](/discovering/connecting-source-control/github.md). The "Integrate Seal into my pipeline" prompt in the welcome view is a starting point for either path; the Agent picks the right one based on what your tenant has connected. ## Downloading a package attestation through the Agent Ask the Agent for a sealed package version's [attestation](/trust/attestations.md) and it surfaces a download button in the thread, backed by the same artifacts the [Sealed packages tab](/discovering/protection-page/sealed-packages-tab.md) produces. Both forms are available: * **PDF attestation**: the human-readable certificate of the vulnerabilities Seal sealed in that version, for handing to a reviewer or auditor. Asking for "the attestation" gives you this form. * **VEX record**: the machine-readable Vulnerability Exploitability eXchange (VEX) record, for scanners and SBOM tooling. Ask for "the VEX attestation" to get this form. Example prompts: * "Download the attestation for `ejs@2.7.4-sp1`." * "Get me the VEX attestation for `lodash` in the `api-server` project." The Agent identifies the sealed package version, then renders a **Download attestation** or **Download VEX attestation** button in-thread. For the PDF form it also offers a **See preview** button that opens the certificate before you download. Click the button to generate and download the file, the same way the Sealed packages tab does. Attestations exist only for sealed package versions, so the Agent offers a download only for a package version Seal has sealed, not for one that has not been sealed. ## Creating a Seal Engineer flow through the Agent You can also ask the Seal AI Agent to create a [Seal Engineer](/using-platform/seal-engineer.md) flow on your behalf — a scheduled recurring task. "Every Monday at 9am, summarize the past week's new vulnerable packages and post to #security," for example. The Agent drafts the flow configuration (template or free-text task, persona, tone, schedule, output channel) and presents it for your approval before creating it. The created flow then runs on its schedule from the Seal Engineer, not from the Agent — the Agent's role is the creation step. ## Conversation history Conversations are saved automatically. The sidebar on the Seal Agent page lists recent conversations and lets you continue an older one or start a new one. Conversations can be archived from the same sidebar when you no longer need quick access; archived conversations stay searchable through the **Archived** view. Each conversation is per-user. The Agent's working memory does not span users; you cannot see another user's conversation or the Agent's prior responses to someone else. ## Related * [Seal Engineer](/using-platform/seal-engineer.md): the schedulable automated-workflow feature, distinct from the Agent. * [Sealing Rules](/using-platform/sealing-rules.md): the canonical home for the rule mechanic that the Agent's write actions go through. * [Attestations](/trust/attestations.md): the PDF and VEX artifacts the Agent's download surfaces, also downloadable from the Sealed packages tab.