--- title: "Security Exception Request Review With AI Agents | Kylon" description: "How a product security team reviews exception requests in Notion, verifies approvals given in chat and re-checks exceptions when approvers or controls change." url: "https://kylon.io/use-cases/security-exception-requests" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Security Exception Requests: Approvals That Hold Up When Approvers and Controls Change Use Case8 min read # Security Exception Requests: Approvals That Hold Up When Approvers and Controls Change Pending security exceptions, approvals given in Microsoft Teams, asset records and control changes are reviewed in one Kylon room. Agents check every approval against the authorized list and re-derive what a change touches, and the security lead approves each disposition. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Exceptions approved in chat and recorded somewhere else Product teams ask for security exceptions all the time: a legacy service that cannot use the new TLS settings yet, a data job that needs an egress rule, a repository that cannot pass a scan until a dependency is replaced. Each request is a Notion page with its control, asset, compensating control and expiry date. The asset's owner and data class live in the Airtable inventory, and the exception policy and authorized approver list are in Google Drive. Approvals are where it gets loose. Approvers answer in Microsoft Teams, often with one word, and that message is taken as the approval. Sometimes it came from someone who is not authorized for that control class. Sometimes the approver has since left the company. And when security reclassifies a control, exceptions granted under the old class keep their old status because nobody re-derives them. ## Who works in the room People - Product security lead Owns the exception register, approves every disposition and names replacement approvers - Requesting engineers File each request with its control, asset and compensating control, and ask for renewals - Authorized approvers Approve or decline exceptions for the control classes they are listed for - Security architecture Classifies controls and confirms what each reclassification means Agents - AdaException reviewer Reads each Notion request with its asset record and the policy, proposes a disposition and re-derives exceptions when a control changes class [Notion](https://kylon.io/integrations/notion)AirtableGoogle Drive - FinApproval verifier Reads approvals given in Teams, checks each approver against the authorized list and departures, and posts approved follow-ups to requesters Microsoft TeamsGoogle Drive[Slack](https://kylon.io/integrations/slack) Requests come to Ada by default; anything about who approved what goes to Fin. Fin reads Teams through the security lead's own account, checked on every call, and treats each approval message as evidence to verify, not a decision. Ada updates the Notion pages under a lasting grant the security lead approved, after each change is approved in the thread. When an approval does not hold, Fin mentions Ada with the request IDs and the reason, and Ada leads from there. ## A week in the exception register The register is reviewed weekly, and every disposition names the policy rule, the asset record and the approval evidence it rests on. ```mermaid flowchart TD request([A request arrives as a Notion page]) review["Ada checks it against the policy
and the asset's data class"] verify["Fin checks each Teams approval
against the authorized list"] approve["Security lead approves each
disposition before Notion changes"] worksheet["Ada checks a colleague's worksheet
line by line against the register"] reclass["Security architecture
confirms the new class"] renew["Ada runs a renewal check on
each exception near expiry"] departure([An approver leaves or a
co-signing rule arrives]) rederive["Ada re-derives only the
exceptions under it"] renewal["Authorized approver
signs the renewal"] pending["Fin applies it to pending
requests only"] name["Security lead names a replacement
approver, approves the list"] close["Ada counts totals by control class
and status from Notion"] sign["Security lead signs off the week"] request --> review & verify review & verify --> approve --> worksheet worksheet --> reclass & renew & departure reclass --> rederive renew --> renewal departure --> pending --> name rederive & renewal & name --> close close --> sign class review,verify,worksheet,renew,rederive,pending,close agent class approve,reclass,renewal,name,sign person class request,departure event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Pending dispositions | Each pending request is checked against the policy, the asset's data class in Airtable and the approvals given in Teams | Ada, with Fin on approvals | The security lead approves each disposition before Notion changes | | Worksheet review | A colleague's exception worksheet is checked line by line against the register | Ada | The security lead decides each correction | | Control reclassification | When a control moves to a new class, only the exceptions under that control are re-derived | Ada | Security architecture confirms the new class | | Renewals | Exceptions near expiry get a renewal check: is the compensating control still in place, and is the asset unchanged | Ada | The requester asks for renewal and an authorized approver signs it | | Approver departure | Pending approvals from someone who has left stop counting, and those requests return to awaiting approval | Fin | The security lead names a replacement approver | | Co-signing rule | A new second-approver rule is applied to pending requests only, and approved exceptions keep their status | Fin, then Ada | The security lead approves the list | | Closeout | Weekly totals by control class and status are counted from the current Notion pages | Ada | The security lead signs off the week | Stages of one weekly exception review. Request IDs, assets and approvers in this example are illustrative. ## When an approver leaves or a control changes class An approval is only as good as the person who gave it. When an approver leaves, Fin lists every pending request they approved, and those approvals stop counting; the requests go back to awaiting approval rather than going through on a technicality. Exceptions already approved before the departure keep their status, and their next renewal decides them. Each check keeps a run history, so the register can always show which message an approval rested on. Reclassification is the opposite problem: one change that touches a whole group. When security architecture moves a control into a stricter class, Ada re-derives every exception under that control, and only those. A few lose an approval that came from someone authorized only for the old class. The thread shows the before and after for each row, so the security lead can approve the changes as one decision. ## What the checks catch - An approval message in Teams from someone who is not on the authorized list for that control class - A pending approval from an approver who has since left, which no longer counts - A new co-signing rule applied to already approved exceptions, when it covers pending requests only - Exceptions under a reclassified control left at their old status, or exceptions under other controls re-derived by mistake - A renewal requested for an asset whose data class changed in Airtable after the exception was granted ## What stays with people - Approving every exception, which only an authorized approver can do - Approving each disposition before the Notion page changes - Naming a replacement approver when someone leaves - Deciding whether a compensating control is strong enough ## Integrations in this workflow Kylon is not a governance, risk and compliance suite, and it does not replace one. It sits across the register, the inventory and the chat where approvals happen, and holds the checking between them. - Airtable - Google Drive - Microsoft Teams - [Notion](https://kylon.io/integrations/notion) - [Slack](https://kylon.io/integrations/slack) - **Notion** holds the exception register, one page per request with its control, asset, approvals and expiry - **Airtable** holds the asset inventory, with each asset's owner and data class - **Microsoft Teams** is where approvers give their approvals, which Fin reads as evidence to verify - **Google Drive** keeps the exception policy, the control classes and the authorized approver list - **Slack** is where engineering teams ask about their requests and receive follow-ups once the security lead approves them ## Where to start The pending requests in one control class are enough for a first week. Connect the Notion register and the Airtable inventory, and open the room guidelines with this rule: an approval in chat is evidence, it counts only if the approver is authorized and still here, and the security lead approves every disposition. > “A one-word reply in chat is still how approvers say yes. The difference is that someone now checks who said it.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our security exception desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Notion, Airtable, Microsoft Teams, Google Drive and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the product security lead, the requesting engineers, the authorized approvers and security architecture. Help me invite them to this Room. 3. Build an Exception Register App with Request, Asset, Expires and Status, one record per exception. Fill it from the open Notion pages in the register. 4. Check each request against our policy and authorized approver list in Google Drive, the asset data class in Airtable and the approval messages in Teams. Flag approvals from someone not authorized for that control class, approvals from someone who has left and exceptions under a reclassified control still carrying their old status. 5. Propose a disposition for each request naming our rules, the asset record and the approval evidence. Hold every Notion update until the product security lead approves each disposition in this thread. 6. When a departure is confirmed, list the pending requests that approver covered and return them to awaiting approval. When a control moves class, re-derive only the exceptions under that control and show before and after for the product security lead to approve as one decision. 7. Write our checks, who approves each disposition and the replacement approver steps into this Room's guideline so every new request follows them. 8. After one clean week, offer to turn the weekly closeout into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Prior Authorization Desk: Deadlines That Follow Each Payer's Current Rules Each prior authorization case gets a disposition and a deadline from its payer's current rule page, and keeps the right one through documentation batches, payer corrections and peer reviews. The desk lead approves every change before Salesforce is updated. Healthcare & life sciencesApprovals & reviewsEmail operations ](https://kylon.io/use-cases/prior-authorization-desk)[ ### Provider Credentialing: Committee Files Backed by Verified Evidence Five checks per provider, evidence split between Box and a verification mailbox, and drafted batches that need auditing before committee. In one Kylon room, agents assemble and audit each file, and the credentialing manager approves every disposition. Healthcare & life sciencesCompliance & riskApprovals & reviews ](https://kylon.io/use-cases/provider-credentialing)