Appearance
KAIDAN video demo transcript
Recorded September 14, 2026. The video uses fictional metadata-only examples in Briard public previews and an isolated KAIDAN demo. The hosted preview and local alert console are separate examples. Response and policy-review stories are simulations. No customer data or real external actions are used.
00:00:00 — See KAIDAN alerts inside Briard
Welcome! Let's see how KAIDAN helps you turn an AI security alert into a clear next step. We'll start exactly where a Briard customer starts: Home. The AI incident alerts panel brings KAIDAN's alert summary into your everyday workspace. You can see what needs attention without opening a technical console first. P1 needs the fastest review. The other priorities help you organize the queue. An alert is a reason to investigate, not proof that harm occurred. This walkthrough uses fictional examples, including an isolated copy of the released KAIDAN application. No customer information or live systems are involved. We'll follow the connection from Briard to KAIDAN, work an alert, and bring the lesson back to a policy review.
00:00:52 — Open the matching alert from Briard
Let's choose Review beside the alert about a tool crossing an approved boundary. Briard opens the matching KAIDAN alert, keeping its title and alert ID together. You can also see the affected tool, priority, and status. That continuity matters: your team starts with the item you selected. Back to Briard alerts returns us to the overview. Open all KAIDAN alerts takes us to the work-account sign-in. Access and any required identity verification still apply before protected evidence or responder actions open. This public preview shows the handoff using made-up records. Next, we'll use a separate fictional refund-agent alert in KAIDAN's full console, so you can see the actual review controls in action.
00:01:42 — Find the alert that needs your attention
Here is KAIDAN's Alerts page. It keeps the queue on the left and the selected alert on the right. These alerts were generated by sending fictional activity records through this isolated application's normal intake. The priority buttons and category filter help you narrow the list. Open alerts shows the items still in play, while All saved alerts preserves the broader history. Let's search for Refund, then select the matching alert. The concern is simple: a tool action lacks recorded approval. This teaching record is P3, so we follow the priority shown rather than assuming every warning is urgent. A clear queue, a familiar search box, and one selected item give a new reviewer a manageable place to begin.
00:02:32 — Read the explanation before deciding
Start with the plain-language explanation. KAIDAN shows what happened, what was affected, what it saw, what remains unknown, and what to do next. Here, the approval record is the issue. We should check it before deciding that the action was allowed or harmful. Notice that the saved business rules are missing in this example. KAIDAN says so; it doesn't invent permission. Review details opens the supporting facts and the activity timeline. The visibility boundary explains the limits of the collected records. Routine collection uses metadata: information about an event, rather than the contents of messages, documents, or model replies. That gives a compliance manager a useful starting point while keeping deeper evidence access a separate, governed decision.
00:03:26 — Record a review without hiding the problem
Now let's acknowledge the alert. That records that someone has seen it; it does not mean the issue is fixed. The Resolve button opens a short review question: What did you find? The choices are Needs action, Allowed use, False alarm, or Not enough proof. These are everyday decisions, supported by the evidence you've reviewed. For this example, we'll choose Needs action. Watch the save button: it now says Save and keep open. After saving, the last review appears on the alert. The concern stays visible because follow-up is still needed. This helps the next person understand what you concluded, without treating an acknowledgment or a closed screen as proof that the underlying problem went away.
00:04:15 — Suggest a fix and start an investigation
A useful alert should lead to a useful next step. In Review details, we can assign the work to ourselves and save a short suggestion for the tool owner. We'll ask the owner to check the refund tool's approval requirement before another privileged action. Save suggestion keeps that recommendation with the alert. The confirmation is explicit: no action was run. When the issue needs a case, choose Investigate. KAIDAN creates an investigation and preserves the contributing alert records as evidence. Choose Investigate again to open it. The alert and case are now linked. Your security team can take the investigation further, while you retain the original concern, the review result, and the proposed next step.
00:05:06 — Check and save the case evidence
The case is the working record of the investigation. Simple view brings the summary, supported answers, and next steps together. Open a linked record to see where the information came from, when it was reported, and which action it describes. You don't need to read code to follow that connection. Before sharing, use the record-chain check. It tests the integrity of the retained evidence, not whether every statement in the source is true. Our local demonstration has no independent outside timestamp, and that limitation remains visible. Download case proof saves the evidence package. The practical benefit is a record your team can review together, with its sources and limits attached, rather than a conclusion copied into an email.
00:05:57 — Understand a larger incident in Simple view
For a larger example, let's open the preloaded cross-tenant disclosure case. That means information may have crossed a boundary between customer environments. KAIDAN has selected relevant records into four evidence-backed answers. The risk check helps prioritize review, and its missing coverage remains visible. Scroll to What we can answer now. The questions are written for people: Was a data safety rule weak or missing? Did a safety tool warn us? Could a tool act without approval? Open the proof and limits beside an answer to see its basis. The timeline then walks through the supported sequence. This is how KAIDAN makes a complex incident easier to examine: it organizes the records, shows the reasoning labels, and keeps the source links close.
00:06:50 — Check whether a response actually worked
Let's connect that investigation work to Briard's public practice story. This is another clearly labeled fictional example you can try without an account. The saved rule lets a proposal assistant search approved information, but not change its settings. The alert reports an attempted settings change. The evidence separates the source report, KAIDAN's interpretation, and a person's decision. Now open the response result. One person proposed a limited change and another approved it. The provider accepted the request, but a follow-up check still found the unsafe action possible. KAIDAN keeps that failed result visible. For a manager, the question is straightforward: did the unsafe action stop, and does allowed work still work? A success message alone is not the answer.
00:07:45 — Keep handoffs and follow-up clear
The response details also show the handoff to the security team. A failed delivery and a later accepted delivery are separate records. Even a delivered message does not turn a failed response into a successful one. Send a copy lets us preview a destination, such as a ticketing workflow. This sample sends nothing. Next, choose Review what we learned. This is the connection back to Briard: the incident can inform a policy owner's review. The original rule, the missing evidence, and the failed response remain part of the story. The owner can decide whether clearer instructions are needed. That closes the learning loop without losing the history of what happened or skipping the follow-up work.
00:08:33 — Bring the lesson back to the policy owner
Here is the proposed policy improvement: keep only the access the tool needs, check both unsafe and allowed actions after a change, and ask the owner to review the next plan if a check fails. The policy owner can accept, revise, or decline. We'll accept these sample words into a draft and record the decision. This does not publish a policy. Download and verify checks the sample file before saving it, keeping the rule, alert, evidence, response, and review together. Back in Briard, My AI policy has separate steps for drafting, approval, publishing, and tracking acknowledgments. KAIDAN supplies the incident evidence; Briard gives your organization a place to review what the rules should say next.
00:09:23 — Start with one alert and one clear next step
You now have a practical route through the platform. See a KAIDAN alert in Briard. Open the matching item. Read the explanation and evidence. Record your review, involve the right owner, and check the response. Then carry the lesson into a policy review when needed. Start with one alert and one clear next step. To begin using Briard or discuss KAIDAN for your organization, visit briard dot A I. You can also contact the team at support at briard dash A I dot app. We'll help you choose a sensible starting point for your team.