[{"data":1,"prerenderedAt":3104},["ShallowReactive",2],{"docs-navigation":3,"docs-search-files":266,"page-\u002Ftools\u002Fmcp-server":1992,"surround-\u002Ftools\u002Fmcp-server":3101},[4,39,118,145,177,216,235],{"title":5,"path":6,"stem":7,"children":8},"Getting Started","\u002Fgetting-started","1.getting-started",[9,13,27,31,35],{"title":10,"path":6,"stem":11,"pro":12},"Overview","1.getting-started\u002Findex",false,{"title":14,"path":15,"stem":16,"children":17,"page":12},"Quick Start","\u002Fgetting-started\u002Fquick-start","1.getting-started\u002F1.quick-start",[18,22],{"title":19,"path":20,"stem":21,"pro":12},"Solo Hunter","\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter","1.getting-started\u002F1.quick-start\u002F1.solo-hunter",{"title":23,"path":24,"stem":25,"pro":26},"Teams","\u002Fgetting-started\u002Fquick-start\u002Fteams","1.getting-started\u002F1.quick-start\u002F2.teams",true,{"title":28,"path":29,"stem":30,"pro":12},"Account and Workspaces","\u002Fgetting-started\u002Faccount-and-workspaces","1.getting-started\u002F2.account-and-workspaces",{"title":32,"path":33,"stem":34,"pro":12},"The Starter Library","\u002Fgetting-started\u002Fstarter-library","1.getting-started\u002F3.starter-library",{"title":36,"path":37,"stem":38,"pro":12},"Your First Suggestions","\u002Fgetting-started\u002Ffirst-suggestions","1.getting-started\u002F4.first-suggestions",{"title":40,"path":41,"stem":42,"children":43},"The Model","\u002Fthe-model","2.the-model",[44,46,70,106],{"title":10,"path":41,"stem":45,"pro":12},"2.the-model\u002Findex",{"title":47,"path":48,"stem":49,"children":50,"page":12},"Methodology","\u002Fthe-model\u002Fmethodology","2.the-model\u002F1.methodology",[51,54,58,62,66],{"title":10,"path":52,"stem":53,"pro":12},"\u002Fthe-model\u002Fmethodology\u002Foverview","2.the-model\u002F1.methodology\u002F0.overview",{"title":55,"path":56,"stem":57,"pro":12},"The CAVET Method","\u002Fthe-model\u002Fmethodology\u002Fcavet","2.the-model\u002F1.methodology\u002F1.cavet",{"title":59,"path":60,"stem":61,"pro":12},"Contextual Hacking","\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking","2.the-model\u002F1.methodology\u002F2.contextual-hacking",{"title":63,"path":64,"stem":65,"pro":12},"Chain Recognition","\u002Fthe-model\u002Fmethodology\u002Fchain-recognition","2.the-model\u002F1.methodology\u002F3.chain-recognition",{"title":67,"path":68,"stem":69,"pro":12},"Worked Chains","\u002Fthe-model\u002Fmethodology\u002Fworked-chains","2.the-model\u002F1.methodology\u002F4.worked-chains",{"title":71,"path":72,"stem":73,"children":74,"page":12},"Components","\u002Fthe-model\u002Fcomponents","2.the-model\u002F2.components",[75,78,82,86,90,94,98,102],{"title":10,"path":76,"stem":77,"pro":12},"\u002Fthe-model\u002Fcomponents\u002Foverview","2.the-model\u002F2.components\u002F0.overview",{"title":79,"path":80,"stem":81,"pro":12},"Technologies","\u002Fthe-model\u002Fcomponents\u002Ftechnologies","2.the-model\u002F2.components\u002F1.technologies",{"title":83,"path":84,"stem":85,"pro":12},"Functionalities","\u002Fthe-model\u002Fcomponents\u002Ffunctionalities","2.the-model\u002F2.components\u002F2.functionalities",{"title":87,"path":88,"stem":89,"pro":12},"Gadgets","\u002Fthe-model\u002Fcomponents\u002Fgadgets","2.the-model\u002F2.components\u002F3.gadgets",{"title":91,"path":92,"stem":93,"pro":12},"Vectors","\u002Fthe-model\u002Fcomponents\u002Fvectors","2.the-model\u002F2.components\u002F4.vectors",{"title":95,"path":96,"stem":97,"pro":12},"Quirks","\u002Fthe-model\u002Fcomponents\u002Fquirks","2.the-model\u002F2.components\u002F5.quirks",{"title":99,"path":100,"stem":101,"pro":12},"Scopes and Levels","\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels","2.the-model\u002F2.components\u002F6.scopes-and-levels",{"title":103,"path":104,"stem":105,"pro":12},"Categories and Tags","\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags","2.the-model\u002F2.components\u002F7.categories-and-tags",{"title":107,"path":108,"stem":109,"children":110,"page":12},"Notespaces","\u002Fthe-model\u002Fnotespaces","2.the-model\u002F3.notespaces",[111,114],{"title":10,"path":112,"stem":113,"pro":12},"\u002Fthe-model\u002Fnotespaces\u002Foverview","2.the-model\u002F3.notespaces\u002F0.overview",{"title":115,"path":116,"stem":117,"pro":12},"Link Metadata","\u002Fthe-model\u002Fnotespaces\u002Flink-metadata","2.the-model\u002F3.notespaces\u002F1.link-metadata",{"title":119,"path":120,"stem":121,"children":122},"Workspace","\u002Fworkspace","3.workspace",[123,125,129,133,137,141],{"title":10,"path":120,"stem":124,"pro":12},"3.workspace\u002Findex",{"title":126,"path":127,"stem":128,"pro":12},"Platforms, Programs, and Assets","\u002Fworkspace\u002Fplatforms-programs-assets","3.workspace\u002F1.platforms-programs-assets",{"title":130,"path":131,"stem":132,"pro":12},"Map an Asset","\u002Fworkspace\u002Fmap-an-asset","3.workspace\u002F2.map-an-asset",{"title":134,"path":135,"stem":136,"pro":12},"Manage Your Scope","\u002Fworkspace\u002Fmanage-your-scope","3.workspace\u002F3.manage-your-scope",{"title":138,"path":139,"stem":140,"pro":12},"Share and Collaborate","\u002Fworkspace\u002Fshare-and-collaborate","3.workspace\u002F4.share-and-collaborate",{"title":142,"path":143,"stem":144,"pro":26},"Clone a Workspace","\u002Fworkspace\u002Fclone-a-workspace","3.workspace\u002F5.clone-a-workspace",{"title":146,"path":147,"stem":148,"children":149},"Nexus Engine","\u002Fnexus-engine","4.nexus-engine",[150,152,156,169,173],{"title":10,"path":147,"stem":151,"pro":12},"4.nexus-engine\u002Findex",{"title":153,"path":154,"stem":155,"pro":12},"Suggestions and Ranking","\u002Fnexus-engine\u002Fsuggestions-and-ranking","4.nexus-engine\u002F1.suggestions-and-ranking",{"title":157,"path":158,"stem":159,"children":160,"page":12},"Checklists","\u002Fnexus-engine\u002Fchecklists","4.nexus-engine\u002F2.checklists",[161,165],{"title":162,"path":163,"stem":164,"pro":12},"Proactive Checklist","\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist","4.nexus-engine\u002F2.checklists\u002F1.proactive-checklist",{"title":166,"path":167,"stem":168,"pro":12},"Reactive Checklist","\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist","4.nexus-engine\u002F2.checklists\u002F2.reactive-checklist",{"title":170,"path":171,"stem":172,"pro":12},"Probes","\u002Fnexus-engine\u002Fprobes","4.nexus-engine\u002F3.probes",{"title":174,"path":175,"stem":176,"pro":12},"Work a Prompt","\u002Fnexus-engine\u002Fwork-a-prompt","4.nexus-engine\u002F4.work-a-prompt",{"title":178,"path":179,"stem":180,"children":181},"Playbooks","\u002Fplaybooks","5.playbooks",[182,184,188,192,196,200,204,208,212],{"title":10,"path":179,"stem":183,"pro":12},"5.playbooks\u002Findex",{"title":185,"path":186,"stem":187,"pro":12},"Create a Playbook","\u002Fplaybooks\u002Fcreate-a-playbook","5.playbooks\u002F1.create-a-playbook",{"title":189,"path":190,"stem":191,"pro":12},"Link Components to a Playbook","\u002Fplaybooks\u002Flink-components-to-a-playbook","5.playbooks\u002F2.link-components-to-a-playbook",{"title":193,"path":194,"stem":195,"pro":12},"Declare Yields","\u002Fplaybooks\u002Fdeclare-yields","5.playbooks\u002F3.declare-yields",{"title":197,"path":198,"stem":199,"pro":12},"Run a Playbook","\u002Fplaybooks\u002Frun-a-playbook","5.playbooks\u002F4.run-a-playbook",{"title":201,"path":202,"stem":203,"pro":12},"Authoring Guide","\u002Fplaybooks\u002Fauthoring-guide","5.playbooks\u002F5.authoring-guide",{"title":205,"path":206,"stem":207,"pro":12},"Requirements","\u002Fplaybooks\u002Frequirements","5.playbooks\u002F6.requirements",{"title":209,"path":210,"stem":211,"pro":12},"Yields and Primitives","\u002Fplaybooks\u002Fyields-and-primitives","5.playbooks\u002F7.yields-and-primitives",{"title":213,"path":214,"stem":215,"pro":12},"Outcomes and History","\u002Fplaybooks\u002Foutcomes-and-history","5.playbooks\u002F8.outcomes-and-history",{"title":217,"path":218,"stem":219,"children":220},"Tools","\u002Ftools","6.tools",[221,223,227,231],{"title":10,"path":218,"stem":222,"pro":12},"6.tools\u002Findex",{"title":224,"path":225,"stem":226,"pro":26},"MCP Server","\u002Ftools\u002Fmcp-server","6.tools\u002F1.mcp-server",{"title":228,"path":229,"stem":230,"pro":26},"Browser Extension","\u002Ftools\u002Fbrowser-extension","6.tools\u002F2.browser-extension",{"title":232,"path":233,"stem":234,"pro":12},"Todoer","\u002Ftools\u002Ftodoer","6.tools\u002F3.todoer",{"title":236,"path":237,"stem":238,"children":239},"Reference","\u002Freference","7.reference",[240,242,246,250,254,258,262],{"title":10,"path":237,"stem":241,"pro":12},"7.reference\u002Findex",{"title":243,"path":244,"stem":245,"pro":12},"Glossary","\u002Freference\u002Fglossary","7.reference\u002F1.glossary",{"title":247,"path":248,"stem":249,"pro":12},"Search the Workspace","\u002Freference\u002Fsearch-the-workspace","7.reference\u002F2.search-the-workspace",{"title":251,"path":252,"stem":253,"pro":12},"Search Syntax","\u002Freference\u002Fsearch-syntax","7.reference\u002F3.search-syntax",{"title":255,"path":256,"stem":257,"pro":12},"Settings","\u002Freference\u002Fsettings","7.reference\u002F4.settings",{"title":259,"path":260,"stem":261,"pro":12},"Dashboard Metrics","\u002Freference\u002Fdashboard-metrics","7.reference\u002F5.dashboard-metrics",{"title":263,"path":264,"stem":265,"pro":12},"FAQ","\u002Freference\u002Ffaq","7.reference\u002F6.faq",[267,271,277,282,287,292,297,302,305,310,315,320,325,330,335,340,343,348,353,358,362,365,370,375,380,385,389,392,397,402,407,412,417,421,424,429,434,439,445,450,455,460,465,470,475,478,483,486,491,496,501,506,511,515,518,523,528,533,538,542,545,550,555,560,565,570,574,577,582,587,592,597,601,604,609,614,619,623,626,631,636,641,646,651,655,658,663,667,671,675,679,683,686,691,695,699,704,708,712,715,720,724,729,733,737,741,744,749,753,758,762,766,770,773,778,783,788,793,798,803,808,813,818,823,828,833,837,840,845,850,855,860,865,870,874,877,882,887,892,897,901,905,908,913,918,923,928,932,937,941,944,949,953,956,961,966,971,976,981,985,988,993,998,1003,1008,1013,1017,1020,1025,1030,1035,1040,1045,1050,1054,1057,1062,1066,1071,1076,1081,1085,1088,1093,1098,1103,1107,1110,1115,1120,1123,1128,1133,1138,1143,1147,1151,1154,1159,1164,1169,1174,1179,1183,1186,1191,1196,1201,1206,1210,1213,1218,1223,1228,1232,1235,1240,1245,1250,1255,1259,1263,1266,1271,1276,1281,1286,1291,1295,1298,1303,1308,1313,1318,1322,1325,1330,1335,1340,1345,1350,1355,1360,1365,1369,1372,1377,1382,1387,1392,1397,1402,1407,1411,1414,1419,1424,1429,1434,1439,1444,1448,1451,1456,1461,1465,1470,1475,1480,1485,1490,1495,1500,1505,1510,1514,1517,1522,1527,1531,1536,1541,1546,1551,1556,1561,1566,1571,1574,1579,1584,1589,1594,1598,1603,1608,1612,1615,1620,1625,1630,1635,1639,1642,1647,1651,1655,1658,1663,1668,1673,1678,1683,1688,1693,1698,1703,1708,1713,1718,1723,1728,1733,1737,1740,1745,1750,1755,1759,1762,1767,1772,1777,1782,1785,1790,1793,1798,1802,1807,1812,1815,1820,1825,1830,1835,1839,1842,1847,1852,1856,1861,1866,1871,1876,1881,1884,1889,1894,1899,1902,1907,1912,1917,1922,1927,1930,1935,1940,1945,1950,1955,1960,1965,1970,1973,1978,1983,1988],{"id":20,"title":19,"titles":268,"content":269,"level":270},[],"The fastest path from an empty workspace to your first playbook run. The sequence below is a starting path — follow it once end to end and you will have used every part of the core loop.",1,{"id":272,"title":273,"titles":274,"content":275,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_1-sign-up-and-seed-the-starter-library","1. Sign up and seed the starter library",[19],"Signing up creates your personal workspace automatically — it starts empty. From the dashboard, click Load Starter Content to seed it with curated components, playbooks, and the Todoer practice target. Seeding is optional, but it gives the engine something to match with from day one. Details: Account and Workspaces, The Starter Library.",2,{"id":278,"title":279,"titles":280,"content":281,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_2-start-with-the-practice-target","2. Start with the practice target",[19],"The starter library includes the Todoer practice target — a platform, a program, and an intentionally unmapped todoer.site asset. Start there: it is a deliberately vulnerable app built for exactly this. When you move to real work, add your own platform, program, and asset the same way. Details: Todoer, Workspace and Manage Your Scope.",{"id":283,"title":284,"titles":285,"content":286,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_3-map-the-asset","3. Map the asset",[19],"Open the asset's Components panel and link what you actually observe — the stack, the features, a behavior you noticed. Record endpoints when you know them, and scope vectors, quirks, and gadgets inside the component they belong to. Details: Map an Asset.",{"id":288,"title":289,"titles":290,"content":291,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_4-work-the-checklist","4. Work the checklist",[19],"Open the asset's Suggestions → Checklists panel. The proactive side asks what is missing; resolve prompts with evidence — link what exists, and only answer \"no\" after checking the full surface. The reactive side lists the objectives your components brought with them. Details: Work a Prompt, Proactive Checklist, Reactive Checklist.",{"id":293,"title":294,"titles":295,"content":296,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_5-run-a-playbook","5. Run a playbook",[19],"Back in Suggestions → Playbooks, open the top-ranked suggestion, execute it against the target, and record the outcome — success, failure, or not applicable. A success earns the playbook's yields as primitives, which can unlock the next playbook in a chain. Details: Run a Playbook, Yields and Primitives.",{"id":298,"title":299,"titles":300,"content":301,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_6-grow-the-vault","6. Grow the vault",[19],"Every engagement adds to the library. When you observe something new, record it as a component; when you learn an escalation, write it as a playbook. The Authoring Guide is the reference for making playbooks that actually fire. New here? Do steps 1–5 in a single sitting on one asset. The loop clicks the first time you watch a suggestion appear because of something you mapped.",{"id":24,"title":23,"titles":303,"content":304,"level":270},[],"Set up a shared workspace where everyone's mapping compounds. This path covers the team-specific setup on top of the Solo Hunter loop. Everything in the core loop still applies — teams just share it.",{"id":306,"title":307,"titles":308,"content":309,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_1-create-the-shared-workspace","1. Create the shared workspace",[23],"One person creates the workspace and owns it. A workspace is the unit of sharing: the component library, playbooks, and outcomes inside it belong to everyone in it. Details: Account and Workspaces.",{"id":311,"title":312,"titles":313,"content":314,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_2-invite-your-members","2. Invite your members",[23],"From workspace settings, invite teammates by email — or share the invite link. Each invite carries a role: Admin — manages workspace settings, members, and everything inside.Member — full access to the vault's content. Details: Share and Collaborate. Granular access controls — per-asset or per-playbook permissions beyond the Admin\u002FMember roles — are not in the product yet. This page will be expanded when they arrive.",{"id":316,"title":317,"titles":318,"content":319,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_3-seed-and-shape-the-library-together","3. Seed and shape the library together",[23],"Seed the Starter Library, then treat the library as an institutional asset: anyone can add components, and every addition makes everyone's suggestions smarter. Encourage the library discipline — reusable, observable, atomic.",{"id":321,"title":322,"titles":323,"content":324,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_4-keep-engagements-separate-reuse-the-setup","4. Keep engagements separate, reuse the setup",[23],"Give each client or engagement its own workspace, and use Clone Workspace to carry over the parts worth reusing — programs & assets, components, playbooks. Details: Clone a Workspace.",{"id":326,"title":327,"titles":328,"content":329,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_5-share-single-things-when-thats-enough","5. Share single things when that's enough",[23],"Not every collaboration needs an invite. Any asset, playbook, or component can be shared as a read-only snapshot link — useful for a second opinion or a client review. Details: Share and Collaborate.",{"id":331,"title":332,"titles":333,"content":334,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_6-connect-your-agents","6. Connect your agents",[23],"If your team works with AI agents, each member can create their own agent connection — scoped to the workspace, capped per member, revocable, and audited.",{"id":336,"title":337,"titles":338,"content":339,"level":276},"\u002Fgetting-started\u002Fquick-start\u002Fteams#whats-next","What's next",[23],"Manage Your Scope — keep large team scopes navigable.The CAVET Method — a shared vocabulary is what makes team knowledge compound.",{"id":29,"title":28,"titles":341,"content":342,"level":270},[],"Sign in, create a workspace, and bring your team into the vault.",{"id":344,"title":345,"titles":346,"content":347,"level":276},"\u002Fgetting-started\u002Faccount-and-workspaces#accounts","Accounts",[28],"Nimbus Vault uses your account to keep your work portable: your profile, plan, and workspace memberships follow you across devices. Sign in from the auth screen, and you land on your workspace dashboard.",{"id":349,"title":350,"titles":351,"content":352,"level":276},"\u002Fgetting-started\u002Faccount-and-workspaces#workspaces","Workspaces",[28],"A workspace is the container for everything — assets, components, playbooks, and notespaces. Most researchers operate in a single workspace; teams share one so that the component library and threat library compound for everyone. Your first workspace is created for you at signup — it starts empty. You can add more workspaces from the dashboard when you want a hard boundary between engagements.",{"id":354,"title":355,"titles":356,"content":357,"level":276},"\u002Fgetting-started\u002Faccount-and-workspaces#members-and-roles","Members and roles",[28],"Invite teammates from workspace settings. Each member has a role: Admin — can manage workspace settings, members, and everything inside the workspace.Member — full access to the workspace's assets, components, and playbooks. Pending invites are visible from the sidebar avatar, so you always know who has not joined yet. Some capabilities — like agent connections — are part of the Pro plan, and workspace ownership is limited by plan (Free accounts own one workspace; Pro accounts up to five). Pro features are marked with the  badge throughout these docs.",{"id":359,"title":337,"titles":360,"content":361,"level":276},"\u002Fgetting-started\u002Faccount-and-workspaces#whats-next",[28],"Seed your workspace so you are not starting from an empty library: the starter library.",{"id":33,"title":32,"titles":363,"content":364,"level":270},[],"Seed your workspace with curated components and playbooks.",{"id":366,"title":367,"titles":368,"content":369,"level":276},"\u002Fgetting-started\u002Fstarter-library#why-seed-the-library","Why seed the library",[32],"The Nexus Engine can only match what exists in your vault. An empty workspace gives you an empty checklist — a seeded one gives you a working library of common technologies, functionalities, gadgets, vectors, quirks, and the playbooks that use them.",{"id":371,"title":372,"titles":373,"content":374,"level":276},"\u002Fgetting-started\u002Fstarter-library#seeding-your-workspace","Seeding your workspace",[32],"New workspaces start empty. From the dashboard, click Load Starter Content to bring the curated set in — components, playbooks, and the Todoer practice target. Seeded content behaves exactly like content you create yourself: you can edit it, extend it, and link it to your assets. It is a head start, not a separate tier. Seed first, then prune. It is faster to delete the few entries you will never use than to author a library from nothing.",{"id":376,"title":377,"titles":378,"content":379,"level":276},"\u002Fgetting-started\u002Fstarter-library#the-practice-target","The practice target",[32],"The seed also includes Todoer — a platform, a program, and an intentionally unmapped todoer.site asset. It is the official practice environment for Nimbus Vault: a real, deliberately vulnerable app you can run the entire loop against without touching a live program. Todoer covers the target and how to practice on it.",{"id":381,"title":382,"titles":383,"content":384,"level":276},"\u002Fgetting-started\u002Fstarter-library#growing-beyond-it","Growing beyond it",[32],"Every engagement adds to your library. When you observe something new on a target, you record it as a component — and from then on the engine can match it everywhere. See components for what earns a place in the library.",{"id":386,"title":337,"titles":387,"content":388,"level":276},"\u002Fgetting-started\u002Fstarter-library#whats-next",[32],"Map your first asset and watch the engine light up.",{"id":37,"title":36,"titles":390,"content":391,"level":270},[],"The moment mapping pays off — where suggestions appear and what you can do with them.",{"id":393,"title":394,"titles":395,"content":396,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#the-moment-it-clicks","The moment it clicks",[36],"Link a couple of components to an asset and the engine has something to say. Open the asset and switch to Suggestions — you'll find two views: Checklists — what's missing: near-miss prompts and the objectives carried by your linked components.Playbooks — what applies now: ranked suggestion cards.",{"id":398,"title":399,"titles":400,"content":401,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#reading-a-suggestion","Reading a suggestion",[36],"Each card is ranked and explainable. It shows a score with a Base and Final value — the base reflects the matched requirements, and the final folds in quirk pressure: enabling quirks present on the asset raise it, mitigating quirks lower it. Sort the list by Score, Name, or Level with the sort control. Click a card to open the playbook in a read-only view — requirements, body, and yields — with a back button. The card's menu jumps to the playbook's own notespace when you need to edit it. If a match looks wrong, fix the data: the suggestion list follows your records, not the other way around.",{"id":403,"title":404,"titles":405,"content":406,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#acting-on-one","Acting on one",[36],"Every card carries three actions, with exact meanings: ActionWhat it records✓ Mark playbook as successfulGrants the playbook's yields as primitives✗ Mark playbook as failedTested, didn't work — the suggestion retires− Mark playbook as not applicableIrrelevant to this asset — retires without a failed test The full run loop — including yield prompts and retraction — is Run a Playbook.",{"id":408,"title":409,"titles":410,"content":411,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#the-checklist-beside-it","The checklist beside it",[36],"Suggestions are the reactive half. The Checklists view is the proactive half: prompts for the required components of near-matches, plus the objectives your components bring with them. Working them is how coverage grows — start with Work a Prompt.",{"id":413,"title":414,"titles":415,"content":416,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#why-its-trustworthy","Why it's trustworthy",[36],"The engine is deterministic: the same asset and the same library always produce the same suggestions in the same order. Nothing is guessed, and nothing changes until you change the data — which makes every result auditable and every fix permanent. See The Nexus Engine.",{"id":418,"title":337,"titles":419,"content":420,"level":276},"\u002Fgetting-started\u002Ffirst-suggestions#whats-next",[36],"Map an asset — feed it more context.Work a prompt — resolve what's missing.Run a playbook — execute and record.",{"id":6,"title":10,"titles":422,"content":423,"level":270},[],"What Nimbus Vault is, how its architecture works, and why it compounds.",{"id":425,"title":426,"titles":427,"content":428,"level":276},"\u002Fgetting-started#what-nimbus-vault-is","What Nimbus Vault is",[10],"Nimbus Vault is a deterministic reasoning engine and knowledge management platform for ethical hackers and security researchers. Everything you observe about a target is captured as machine-readable context, and everything you know about attacking it is applied back to you as ranked, explainable suggestions. It exists because of a specific bottleneck. The hard part of hunting is rarely the testing itself. It's that nothing connects what you observe on a target to what you know about attacking it. Write-ups get bookmarked and forgotten. Techniques stay siloed by vulnerability class. And when you're looking at a live target, the knowledge you need is spread across notes, browser tabs, and memory. Information transfers between hunters, but capability does not. Nimbus closes that gap. You map what you see, and the engine applies what you know.",{"id":430,"title":431,"titles":432,"content":433,"level":276},"\u002Fgetting-started#the-loop","The loop",[10],"Everything in the product runs on one cycle: Map. Observe a target and record its components in Nimbus. (Map an Asset)Match. The engine compares your playbooks against what you mapped and ranks the ones that apply. (The Nexus Engine)Confirm. Proactive and reactive checklists turn gaps into concrete next questions. (Checklists)Execute. Run the playbooks the engine surfaced, on the target, within program rules. (Run a Playbook)Earn. Record the outcome. A successful playbook yields primitives, and those unlock the next playbook in a chain. (Yields and Primitives) Then the loop repeats, and each pass leaves you with a sharper vault. Think of it as a SIEM for offensive security. A SIEM ingests logs, normalizes them into a schema, correlates them against detection rules, and alerts you to what matters. Nimbus runs the same pipeline over your reconnaissance. Mapping is ingestion, the component model is the schema, playbooks are the detection rules, and suggestions and prompts are the alerts. The difference is the analyst. That's still you, deciding, testing, and executing on a live target.",{"id":435,"title":436,"titles":437,"content":438,"level":276},"\u002Fgetting-started#architecture","Architecture",[10],"The platform has three layers: the Component Library, the Threat Library, and the Nexus Engine. A link connects them. A link is the connection between two things in your vault: an asset and a component, a playbook and a requirement, or an earned primitive and the playbook that earned it. Each link also carries the metadata the engine reads (Link Metadata).",{"id":440,"title":441,"titles":442,"content":443,"level":444},"\u002Fgetting-started#the-component-library-observation","The Component Library: observation",[10,436],"Assets hold the context of a target, and five component types describe it: Technologies: what the target is built with.Functionalities: what it does.Gadgets: chainable exploit primitives.Vectors: how input reaches the application.Quirks: observable behaviors that enable or block attacks. Knowing what a target has is only the start. Where each thing lives matters just as much. Say you notice that a target uses CSRF tokens. That might be true for the application as a whole, or it might be true of one email change functionality only. The second observation is far more useful, because it tells you exactly where to test. Nimbus lets you record either one. At the asset level, an observation applies to the whole application. When you link an observation to a component, it applies only to the exact component where you saw it, for example, a search bar functionality exhibiting the input reflection quirk. The engine treats the scoped version as stronger evidence and ranks suggestions accordingly (Scopes and Levels).",3,{"id":446,"title":447,"titles":448,"content":449,"level":444},"\u002Fgetting-started#the-threat-library-knowledge","The Threat Library: knowledge",[10,436],"The other half is what you know about vulnerabilities. A playbook is a testing recipe. It lists the components an asset needs to have for the attack to make sense, and how much each one matters: Required components are hard gates. The playbook stays hidden until every one of them is satisfied.Optional components don't gate anything, but they affect the confidence score.Enabling quirks make a playbook more viable. Mitigating quirks work against it. One confirmed mitigation, such as a robust sanitizer or a strict CSP, can outweigh several enablers, and the engine is built to reflect that. The Authoring Guide explains how to write playbooks that fire precisely.",{"id":451,"title":452,"titles":453,"content":454,"level":444},"\u002Fgetting-started#the-nexus-engine-reasoning","The Nexus Engine: reasoning",[10,436],"For each asset, the Nexus engine answers one question: which of your playbooks apply, and how confident should you be in each? It works through four stages to answer this question: Hard gates. The engine first checks every required component against the asset. If even one is missing, the playbook is excluded, no matter what else it has going for it.Overlap and structure. Playbooks that pass the gates are scored on how much of what they list is actually present on the asset, including technology version constraints, and on how precisely each part matches.Quirk weighting. Next, the engine weighs the quirks. Precise evidence counts for more, so a quirk scoped to a component beats one recorded on the whole asset. Role matters too: enabling quirks raise confidence, and mitigating quirks pull it down harder.Confidence and ranking. The signals combine into a final score, and the playbooks are ranked by it. There is a deliberate ceiling: without direct behavioral evidence, a match can never claim absolute certainty. Every stage can be audited, and every result can be reproduced. The same data always produces the same suggestions (Suggestions and Ranking).",{"id":456,"title":457,"titles":458,"content":459,"level":276},"\u002Fgetting-started#benefits","Benefits",[10],"No more tunnel vision. Tunnel vision is hunting one vulnerability class on every target, whether or not the target's context supports it. With Nimbus, you map the target first, and the engine surfaces every technique that fits, including ones you learned months ago and forgot.Your memory moves outside your head. You don't have to worry about \"use it or lose it.\" Study several techniques in one sitting, encode them, and trust the vault to bring each one back when its context shows up on a real target. Learning in bulk becomes safe.Every mapped asset is searchable. When a new technique or advisory drops, you don't re-scan targets by hand. You search the vault for assets that match its conditions and get a ranked list in seconds (Search the Workspace).Knowledge compounds in both directions. A new playbook applies to every matching asset, past and future. A new observation changes which playbooks fire. Each addition makes the whole system sharper, not just bigger, and it does so retroactively.Decisions stop being arbitrary. Instead of asking \"where do I start?\", you see what applies and what it's worth, with the reasoning shown. Coverage no longer depends on how much energy you have that day.Teams share capability, not just notes. You don't have to study a teammate's playbook before you need it. It fires against your assets automatically, and you open it when it applies. You can even benefit from a technique you don't know exists, because the engine brings it to you at the moment it's relevant. The knowledge stays with the team instead of leaving with individuals.The vault is ready for agents. The structured graph of components, requirements, and playbooks is machine-readable by design. Your agents reach it through the MCP server and reason against your actual playbooks and targets, not generic training data. And because the engine's rankings are deterministic, an agent works from what applies to your target instead of guessing.",{"id":461,"title":462,"titles":463,"content":464,"level":276},"\u002Fgetting-started#no-guessing-no-autopilot","No guessing, no autopilot",[10],"Two things are worth stating plainly. The engine does not guess. It isn't an AI producing plausible-sounding attacks. It follows fixed rules, much like a spreadsheet formula: the same inputs always give the same answer, and you can see exactly how it got there. Every recommendation is a logical conclusion drawn from evidence you provided, and it traces back to specific components and behaviours you observed. Nimbus does not find bugs for you. It doesn't replace understanding your target, and it doesn't guarantee findings. The hunting still comes from you: your curiosity, your intuition & your willingness to chase a rabbit hole. What Nimbus does is make sure nothing you've learned, mapped, or confirmed goes to waste. It's a co-pilot, not an autopilot.",{"id":466,"title":467,"titles":468,"content":469,"level":276},"\u002Fgetting-started#key-features","Key features",[10],"Playbooks: encode attack knowledge once, and the engine applies it everywhere it fits.The Nexus Engine: ranked suggestions with the reasoning behind them, plus the proactive checklist.Checklists: proactive prompts and reactive objectives, with probes that show you how to check.Yields and Primitives: successful playbooks grant capabilities, so chains build themselves.Search the Workspace: query every asset and component at once, including version-aware technology lookups.Tools: the MCP server for agent access, and the browser extension for tagging without leaving the target.The CAVET model: components, scopes, notespaces, and the methodology underneath.",{"id":471,"title":472,"titles":473,"content":474,"level":276},"\u002Fgetting-started#where-to-start","Where to start",[10],"Just want to use it? Follow Quick Start: Solo Hunter.Setting up a team? Follow Quick Start: Teams.Want the ideas first? Read The CAVET Method, then come back.",{"id":52,"title":10,"titles":476,"content":477,"level":270},[],"The thinking behind the tooling — CAVET, contextual hacking, and chains.",{"id":479,"title":480,"titles":481,"content":482,"level":276},"\u002Fthe-model\u002Fmethodology\u002Foverview#this-section-is-about-the-method","This section is about the method",[10],"Nimbus Vault implements a methodology; it is not just a feature set. The three pages here are that methodology, described on its own terms. The CAVET Method — Component Analysis & Vulnerability Enumeration Technique: the component ontology and the Observe → Probe → Reason → Test workflow.Contextual Hacking — the mindset: hunt the context that creates vulnerabilities, rather than forcing vulnerability classes onto targets.Chain Recognition — how earned capabilities turn isolated findings into compound attack paths.Worked Chains — three real compound attacks, retold in component terms. Everything the product does — the library, the playbooks, the engine, the checklist — exists to make this way of working systematic. If you want the practical version, start with the Authoring Guide; if you want to know why any of it is shaped the way it is, read on here.",{"id":56,"title":55,"titles":484,"content":485,"level":270},[],"Component Analysis & Vulnerability Enumeration Technique — the ontology and workflow behind Nimbus Vault.",{"id":487,"title":488,"titles":489,"content":490,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#what-cavet-is","What CAVET is",[55],"CAVET — Component Analysis & Vulnerability Enumeration Technique — is a systematic approach to offensive security testing. It answers one central question: What components are present, what properties do they have, and which attacks do these enable? Where defensive frameworks model what could go wrong during design, CAVET models what is testable during an engagement: it is evidence-based, built from observations of the running system.",{"id":492,"title":493,"titles":494,"content":495,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#the-five-components","The five components",[55],"CAVET's ontology is the same one Nimbus Vault's component library is built on. Each type isn't just a category — it plays a distinct role in how vulnerabilities come to exist. Technologies — the constraint space. The frameworks, languages, platforms, and infrastructure a target runs on. More than \"what it's built with\": technologies define the universe of what is possible and impossible — the constraint space attacks must live inside. Functionalities — trust boundaries. The discrete things the app does for users: login, upload, search, payments. Each is a boundary where the application accepts external input and makes a promise about what it will do with it. Vulnerabilities are broken promises. Gadgets — unintended capabilities. Mechanisms built for legitimate purposes that can be repurposed: innerHTML, dangerouslySetInnerHTML, a PostMessage Listener, a List-Unsubscribe header, deserialization, URLs the server fetches. Gadgets are the force multipliers that escalate simple bugs into impact. Vectors — the application's perception system. How attacker-controlled input reaches the application and how responses travel back: parameters, headers, cookies, bodies, file metadata. Vectors are the lenses through which the app sees the world — the same payload behaves differently depending on which lens it arrives through. Quirks — emergent properties and ground truth. What testing reveals about how the components actually behave: reflects input without encoding, no CSRF Token present, an Unsafe Prototype-Chain Lookup, a default-src 'self' CSP. Quirks are what is — and they come in two directions: enabling and mitigating.",{"id":497,"title":498,"titles":499,"content":500,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#the-workflow","The workflow",[55],"The ontology is half of CAVET. The other half is the order of operations: Observe — map the technologies, functionalities, gadgets, and vectors systematically.Probe — test the observed surface to discover its quirks.Reason — match the confirmed context against known attack patterns.Test — execute against the patterns that the context supports, and only those. The order is not a suggestion. You cannot reason about which attacks apply without knowing the quirks; you cannot probe for the properties of something you haven't observed. Skipping or rearranging the stages is what produces guesswork — payloads sprayed at inputs that were never contextualized. And the cycle repeats: testing produces new observations, probing confirms new quirks, and the context gets sharper every pass.",{"id":502,"title":503,"titles":504,"content":505,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#from-theory-to-practice","From theory to practice",[55],"CAVET wasn't always this formal. It began as \"contextual hacking\" — a way of describing how experienced hunters actually work — and only later acquired its ontology and workflow. The formalization is what makes it teachable: Map write-ups into components. Deconstructing a public report into technologies, functionalities, gadgets, vectors, and quirks is the fastest way to internalize the ontology.A missed quirk is the tell. If a write-up's decisive detail was a behavior you hadn't considered, the gap is in your probing, not your payloads.Synthesis is the goal. The final skill is constructing a hypothetical bug from components alone — before you have seen it.",{"id":507,"title":508,"titles":509,"content":510,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#how-nimbus-vault-implements-it","How Nimbus Vault implements it",[55],"The Component Library is the mapping layer — observations structured by the five types.The Threat Library is the knowledge layer — playbooks that encode attack patterns in the same language.The Nexus Engine is the logic layer — deterministic matching that connects the two. That correspondence is the point: the tool is not a companion to the methodology, it is the methodology made operational.",{"id":512,"title":337,"titles":513,"content":514,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcavet#whats-next",[55],"Contextual Hacking — where this way of working began.Chain Recognition — the compound case.",{"id":60,"title":59,"titles":516,"content":517,"level":270},[],"Hunt the context that creates vulnerabilities, not the vulnerability class.",{"id":519,"title":520,"titles":521,"content":522,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#the-methodology-gap","The methodology gap",[59],"Most bug bounty education teaches isolated techniques: a video on SQL injection, a write-up on IDOR, a lab on XSS. The pieces are real, but nothing connects them into a process. The result is a familiar set of symptoms — scattered notes, bookmarked techniques you never revisit, and lab skills that never quite transfer to a live target. The failure mode has a name: single-vulnerability tunnel vision. \"Pick one vulnerability class and hunt it\" is common advice, and well-intentioned — but without the missing step, it turns every input field into \"the perfect spot for XSS,\" even in an application that handles input perfectly. The missing step is context. The advice should be: stick to one vulnerability class, but learn the context that gives birth to it.",{"id":524,"title":525,"titles":526,"content":527,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#vulnerabilities-depend-on-context","Vulnerabilities depend on context",[59],"Every vulnerability class has conditions it needs: An OAuth flaw only exists where OAuth exists and is misconfigured.A race condition needs asynchronous processing colliding with critical state.SSRF lives in applications that make outbound requests from user input. None of these are lurking \"everywhere.\" They are born from specific interactions between technologies, functionalities, gadgets, vectors, and quirks — the CAVET components. So the working method inverts: instead of forcing a technique onto a target, you map the application's context and let it reveal the attack paths it actually supports. Hunting for context lets the vulnerabilities find you. This is what experienced hunters do instinctively: recon first, analyze patterns, choose techniques from evidence. Contextual hacking makes the instinct explicit — and makes a failed hypothesis productive, because the context you mapped is reusable knowledge regardless of which attack it eventually supports.",{"id":529,"title":530,"titles":531,"content":532,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#map-the-context-then-test","Map the context, then test",[59],"Contextual hacking has a practical loop: Map — technologies, functionalities, gadgets, vectors, quirks. The same five types used everywhere in Nimbus Vault.Probe — test the mapped surface for the properties (quirks) that decide exploitability.Reason — hold the context against your library of attack patterns.Test — apply the techniques the context supports, with probing, bypass, and exploitation techniques as your toolkit. Techniques are still essential — they are how you probe, bypass, and exploit. What contextual hacking changes is when they enter: after the context says they apply, not before. (\"Apply first, understand second\" is how you waste an engagement; the loop above is the alternative.)",{"id":534,"title":535,"titles":536,"content":537,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#the-team-version","The team version",[59],"The same idea scales past one person. A shared context base — where every mapped component, confirmed quirk, and tested technique compounds — means knowledge stops being personal and starts being infrastructural: A teammate's earlier finding surfaces on your target because the components match.Nothing learned is forgotten, and nothing is relearned.The workspace gets smarter with every engagement, not just the individual. That last property — knowledge that compounds relationally instead of accumulating as notes — is the \"context engine\" idea Nimbus Vault is built on.",{"id":539,"title":337,"titles":540,"content":541,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#whats-next",[59],"The CAVET Method — the formal ontology and workflow.Chain Recognition — what happens when findings compose.",{"id":64,"title":63,"titles":543,"content":544,"level":270},[],"How earned capabilities turn isolated findings into compound attack paths.",{"id":546,"title":547,"titles":548,"content":549,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#why-chains-are-invisible","Why chains are invisible",[63],"A single-vulnerability view of a target has a blind spot: the interesting bugs are often compounds. A low-impact write becomes a zero-click takeover when it can reach a served file; an XSS in a low-value frame becomes an admin compromise when a postMessage bridge carries it into the main app; a missing re-authentication check turns an email swap into an account takeover. Component matching alone struggles with this. It can surface each playbook that applies, but it has no language for \"these two things together are a chain\" — because the second step only becomes true after the first one succeeds.",{"id":551,"title":552,"titles":553,"content":554,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#earned-capabilities","Earned capabilities",[63],"The insight behind chain recognition is that some things become true about a target only when you achieve them. These are primitives: fundamental capabilities like arbitrary file write, or execution in a victim's browser, that you earn by successfully weaponizing a vulnerability. So playbooks declare what they yield on success, and the engine treats those yields as new matching signals: Archive Path Traversal       → success → grants: Arbitrary File Write\n  └─ overwrite-a-served-file playbook\n       (requires the earned primitive)\n                             → success → grants: Stored XSS\n            └─ escalation playbook\n                 (requires the Stored XSS capability)\n                             → leads to account takeover The engine doesn't need to know the whole chain upfront. It follows the primitive graph one step at a time — and each success unlocks the next suggestion automatically. See Yields and Primitives for the mechanics.",{"id":556,"title":557,"titles":558,"content":559,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#observed-or-earned","Observed or earned",[63],"What a chain requirement targets decides when it can fire: A gadget (Stored XSS) is satisfied the normal way — by mapping it on the asset, whether observed during recon or granted by a yield. The chain can fire from observation alone.A self-contained primitive (Arbitrary File Overwrite) is satisfied only by earning it. There is nothing to observe, so the chain stays invisible until the foundation has been demonstrated on this target. That is the difference between reach and precision. When the delivery path matters, require the self-contained primitive; when any sighting is enough, the gadget requirement is enough.",{"id":561,"title":562,"titles":563,"content":564,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#meta-playbooks","Meta-playbooks",[63],"Escalation knowledge doesn't care how the capability was acquired. An escalation playbook that requires Arbitrary File Overwrite applies no matter which route granted it — archive traversal, an upload flaw, anything that yields it. This is the meta-playbook pattern: write the escalation once, and every route to that primitive inherits it. As more playbooks yield the same primitive, the escalation playbook gets more valuable without being touched.",{"id":566,"title":567,"titles":568,"content":569,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#what-chains-look-like","What chains look like",[63],"Compound paths tend to hide in the same places — worth keeping in the back of your head while mapping: A write that reaches a served surface — archive extraction, file overwrite, template injection: the question is whether what you wrote is ever read or executed.A trust bridge between contexts — postMessage handlers, iframes, subdomain-to-subdomain flows: weak origin checks turn a low-value frame into a foothold in the main app.Identity flows without re-authentication — email change, password reset, invite flows: the pivot from \"some execution\" to \"account takeover\" is often a missing confirmation, not a missing exploit.Parser and semantic differences — duplicate parameters, normalization mismatches, type coercion: two components that disagree about what the same input means. None of these are playbooks — they are shapes that recurring chains take. Recognizing the shape is how you know which primitives are worth pursuing on a target.",{"id":571,"title":337,"titles":572,"content":573,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#whats-next",[63],"Worked Chains — the shapes above, told as full narratives.Yields and Primitives — the mechanics behind everything on this page.Authoring Guide — writing the playbooks that gate and grant capabilities.",{"id":68,"title":67,"titles":575,"content":576,"level":270},[],"Three real compound attacks, retold in component terms. These are real findings retold as chains: each step shows what was observed, what capability it earned, and what that unlocked next. Read them the way you would map a target — as components, capabilities, and the playbooks that connect them. Targets are anonymized; the shapes are the lesson.",{"id":578,"title":579,"titles":580,"content":581,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-invite-page-write","The invite-page write",[67],"Observation. An invite-acceptance page fired an API call on load, taking an invite code from the URL and placing it into the request path client-side. The write. The code was not validated before being used as a path segment — and browsers collapse ..\u002F sequences during request construction. The page's own authenticated session and CSRF token rode along with every request. Result: authenticated request forgery with an attacker-controlled path. What it earned. With the email-change endpoint accepting the same JSON body shape the page already sent, the primitive became \"change the victim's email\" — no different-origin trickery required. Escalation. With the email changed, a legitimate password reset delivered to the attacker. After login, the second-factor check used a truthy lookup on a plain object — so a prototype-chain value (like __proto__) passed the gate. Full account takeover. The shape: a client-side sink that trusts a URL parameter → an authenticated primitive the app performs for you → an identity flow without re-authentication → a semantic bug in a gate.",{"id":583,"title":584,"titles":585,"content":586,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-bridge","The bridge",[67],"Observation. A support widget embedded in the main app, served from a second origin. A chat renderer that built HTML before sanitizing it, with a sanitizer hook permissive enough to let a single event handler through. Step one. Self-XSS in the low-value widget frame — interesting to nobody, because who attacks themselves? What it earned. JavaScript execution in the widget's origin. On its own: worthless. The bridge. The widget communicated with the parent over postMessage, and the parent's origin check used substring matching — so an origin like support.site.attacker-domain.com passed. Worse, the parent exposed a debug channel that evaluated received code. Escalation. From the compromised widget, one message through the bridge became DOM XSS in the main application. Then the legitimately embedded widget was used to send a crafted message as the victim — landing stored XSS in a support agent's session. frame-ancestors protections were irrelevant: the parent context was fully trusted. The shape: a rare execution context in a low-value frame → a weakly checked trust bridge between contexts → execution where it counts.",{"id":588,"title":589,"titles":590,"content":591,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-consent-confusion","The consent confusion",[67],"Observation. An OAuth authorization endpoint validated the redirect_uri correctly — against a value stored in the session. The quirk. A separate consent route re-read redirect_uri from the request instead, so the value that was validated and the value that was used came from different sources. (The validation was itself prefix-based, so a look-alike domain would also have passed.) What it earned. The authorization code redirected to an attacker-controlled address. Escalation. The code could be exchanged without a client secret, and it did not expire — making the interception a persistent backdoor rather than a one-shot. The shape: one flow validates, a sibling flow trusts → parameter confusion → a token that outlives the moment it was stolen.",{"id":593,"title":594,"titles":595,"content":596,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#what-to-take-from-these","What to take from these",[67],"Identity flows are where \"some execution\" becomes \"account takeover.\" Email change, password reset, OAuth — check for re-authentication and validation consistency every time.Trust bridges amplify everything. postMessage handlers, iframes, subdomains: the origin check is the whole security model, and substring matching is not a check.Small quirks decide chains. A truthy lookup, a client-side path sink, a consent route re-reading a parameter — none are impressive alone, all are pivotal in sequence.Each step here could be a playbook. That is the point: map the components, write the trigger, let the engine carry you from one earned capability to the next.",{"id":598,"title":337,"titles":599,"content":600,"level":276},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#whats-next",[67],"Chain Recognition — the mechanics behind these narratives.Yields and Primitives — how a chain is encoded in the vault.",{"id":76,"title":10,"titles":602,"content":603,"level":270},[],"What components are, the five types, and what earns a place in the library.",{"id":605,"title":606,"titles":607,"content":608,"level":276},"\u002Fthe-model\u002Fcomponents\u002Foverview#the-vocabulary-of-the-vault","The vocabulary of the vault",[10],"Components are the shared vocabulary of your vault. Every observation you make about a target becomes a component, and every observation the Nexus Engine reasons about is one. There are five kinds, each answering a different question: TypeQuestion it answersExampleTechnologyWhat is it built on or running?Node.js, nginx, PostgreSQLFunctionalityWhat does it do for the user?File Upload, Password-ResetGadgetWhat additional capability rides along?innerHTML, PostMessage ListenerVectorWhat is the specific way in?SVG, Oauth redirect_uri ParameterQuirkWhat behavior could tip an attack?Unsafe Prototype-Chain Lookup, CORS Origin Reflection Technologies and functionalities usually sit directly on an asset. Gadgets, vectors, and quirks can be scoped — observed inside the parent component they came from. Scoping is what lets the engine reason precisely instead of broadly, and it is usually the difference between a suggestion worth acting on and one worth ignoring.",{"id":610,"title":611,"titles":612,"content":613,"level":276},"\u002Fthe-model\u002Fcomponents\u002Foverview#what-earns-a-place-in-the-library","What earns a place in the library",[10],"The library is not a notes app. Before creating a component, ask: will this be useful on another asset? Reusable — it describes a class of things, not one-off trivia about one host.Observable — you confirmed it on a target. Speculation belongs in a prompt, not the library.Atomic — one idea per component. \"Next.js with 'unsafe-inline' in its CSP and an exposed \u002Fdebug route\" is three components, not one. Components that fail this test become noise that pollutes matching for every asset.",{"id":615,"title":616,"titles":617,"content":618,"level":276},"\u002Fthe-model\u002Fcomponents\u002Foverview#organizing-the-library","Organizing the library",[10],"Categories group components by theme and power the engine's structured matching. Tags are lighter labels for slicing the library and attaching conditions in playbooks — a category plus a tag is one of the most precise requirements a playbook can express. See Categories and Tags.",{"id":620,"title":337,"titles":621,"content":622,"level":276},"\u002Fthe-model\u002Fcomponents\u002Foverview#whats-next",[10],"Technologies — the most common entry point.Scopes and levels — how components nest inside their parents.Reactive Checklist and Probes — a component's tests, and how-to-check notes.Categories and tags — the library's organizing layers.The CAVET Method — why these five types exist.Notespaces and endpoints — where observations live once linked.",{"id":80,"title":79,"titles":624,"content":625,"level":270},[],"The frameworks, servers, languages, and platforms a target is built with.",{"id":627,"title":628,"titles":629,"content":630,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#what-a-technology-is","What a technology is",[79],"A technology is something a target is built with or runs on: a language runtime (Node.js, PHP), a web server or proxy (nginx, Envoy), a datastore (PostgreSQL, Redis), a framework (Express, Next.js), a platform (Cloudflare, Netlify). In CAVET terms, technologies define the constraint space — the universe of what is possible on this target and what is not.",{"id":632,"title":633,"titles":634,"content":635,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#why-they-matter","Why they matter",[79],"Technologies are the anchor for everything version-, configuration-, or runtime-specific. A quirk almost never applies \"everywhere on the asset\" — it applies to a specific technology in a specific state. Linking the technology gives those observations a place to live and gives the engine a scoping anchor.",{"id":637,"title":638,"titles":639,"content":640,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#how-they-link","How they link",[79],"Usually directly to the asset — a technology is a property of the thing you are testing. Behavior specific to it is captured as scoped children: a quirk inside the technology (Unsafe Prototype-Chain Lookup inside Node.js)a vector inside the part of the stack it affects A quirk scoped to a technology scores more specifically than the same quirk floating on the asset, and playbooks that require the pairing can only match when the structure is right.",{"id":642,"title":643,"titles":644,"content":645,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#library-hygiene","Library hygiene",[79],"One entry per technology, kept stable and undated. Node.js is knowledge you keep forever; Unsafe Prototype-Chain Lookup is a quirk scoped to it; the version condition is a detail on that observation.",{"id":647,"title":648,"titles":649,"content":650,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#in-the-app","In the app",[79],"Create one from Technologies in the sidebar with Add Technology: FieldRequiredNotesNameYesAutocompletes from the technology catalogue — picking a match fills category, description, and logoCategoryYese.g. Web framework; suggestions come from categories already in useDescriptionNoWhat the technology doesVendorNoWho makes or maintains itLogo URLNoOptional branding for tables and cardsTagsNoComma-separated (backend, node, wip) The technology notespace carries a Components tab no other type has: default quirks, common vectors, and common gadgets that assets inherit when they link this technology. Each default carries an Inheritance Level (Asset or Component), an Inheritance Mode (Auto or Manual), and — for quirks — a Default Polarity (Present \u002F Absent). \"This stack usually exhibits an unsafe prototype-chain lookup\" becomes one link instead of dozens. When you link a technology to an asset and know the version, record it in the link's Version field — it feeds version-constrained playbook requirements.",{"id":652,"title":337,"titles":653,"content":654,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#whats-next",[79],"Functionalities — what the stack does for users.",{"id":84,"title":83,"titles":656,"content":657,"level":270},[],"What a target does for its users — and where most attack surface lives.",{"id":659,"title":660,"titles":661,"content":662,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#what-a-functionality-is","What a functionality is",[83],"A functionality is something the target does for its users: file upload, password reset, signup, full text search, member invites, contact forms, checkout. In CAVET terms, functionalities are trust boundaries: places where the application accepts outside input and makes a promise about what it will do with it. Vulnerabilities are broken promises.",{"id":664,"title":633,"titles":665,"content":666,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#why-they-matter",[83],"Most attack surface is functionality-shaped. Playbook requirements frequently start from a functionality, and the vectors you find while testing one almost always belong to it — which makes functionalities the natural parent for scoped observations.",{"id":668,"title":638,"titles":669,"content":670,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#how-they-link",[83],"Usually directly to the asset, with vectors, quirks, and gadgets hanging off them as scoped children: File Upload            (functionality)\n  └─ SVG               (vector)\n  └─ File Type Conversion (quirk) Scoping a vector inside the functionality that produces it is what makes a suggestion specific. The engine can tell \"this asset has an SVG vector somewhere\" apart from \"this asset has one inside its avatar uploader\" — and only one of those is usually worth acting on.",{"id":672,"title":643,"titles":673,"content":674,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#library-hygiene",[83],"Name the capability, not the endpoint. File Upload is a component; POST \u002Fapi\u002Favatar on admin.example.com is where you recorded it — the endpoint belongs on the link, not in the name.",{"id":676,"title":648,"titles":677,"content":678,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#in-the-app",[83],"Create one from Functionalities with Add Functionality: Name (required), Category (required), Aliases (alternate names like Upload or File Transfer, so the same thing is findable under different wording), Description, and Tags. Functionalities link directly to assets, and they're usually the first type you map — the bones of the target's attack surface. They're also where scoped children accumulate: vectors live inside the functionality that produces them, quirks where the behavior was observed. Playbook requirements for those children demand the exact parent (exact-parent rule), so linking a child to the right functionality matters twice.",{"id":680,"title":337,"titles":681,"content":682,"level":276},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#whats-next",[83],"Gadgets — the capabilities that ride along.",{"id":88,"title":87,"titles":684,"content":685,"level":270},[],"Extra capabilities that ride along with a target, beyond its intended purpose.",{"id":687,"title":688,"titles":689,"content":690,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#what-a-gadget-is","What a gadget is",[87],"A gadget is an extra capability that rides along with the target — not the purpose of the system, but a surface it exposes anyway: innerHTML, a PostMessage Listener on a third-party widget, a List-Unsubscribe header, or a vulnerability class that behaves as a gadget — Stored XSS, Open Redirect, CSPT. In CAVET terms, gadgets are unintended capabilities — mechanisms built for legitimate purposes that attackers repurpose into force multipliers.",{"id":692,"title":633,"titles":693,"content":694,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#why-they-matter",[87],"Gadgets are where \"it also does this\" turns into attack surface. They are frequently discovered while mapping something else — you are testing the support chat and notice its PostMessage Listener — and each one seeds its own vectors and quirks. Left unrecorded, they are invisible to the engine.",{"id":696,"title":638,"titles":697,"content":698,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#how-they-link",[87],"Directly on the asset, or scoped inside the technology that exposes them (innerHTML inside Handlebars). If a gadget exists only because of a specific parent component, scope it there.",{"id":700,"title":701,"titles":702,"content":703,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#functionality-vs-gadget","Functionality vs. gadget",[87],"A functionality is what the product is for — Password-Reset. A gadget is what came along with it — the List-Unsubscribe header the mailer happens to expose. When in doubt: if users are supposed to use it, it is a functionality; if it is a side door, it is a gadget.",{"id":705,"title":648,"titles":706,"content":707,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#in-the-app",[87],"Create one from Gadgets with Add Gadget: Name (required), Category (required), Description, and Tags. Link gadgets directly to an asset, or scoped inside the technology that exposes them. In playbooks they play three roles: requirements (often optional — gadgets vary by implementation and resist black-box confirmation), nested children (Add CLGV \u002F Add CLGQ on a gadget link), and yields (toggle Yields on success to mark a gadget as a playbook output — see Declare Yields).",{"id":709,"title":337,"titles":710,"content":711,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#whats-next",[87],"Vectors — the specific ways in.",{"id":92,"title":91,"titles":713,"content":714,"level":270},[],"The specific mechanisms that turn observed behavior into a reachable attack.",{"id":716,"title":717,"titles":718,"content":719,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#what-a-vector-is","What a vector is",[91],"A vector is the specific way in — the mechanism that turns observed behavior into a reachable attack: SVG, .zip uploads, an Oauth redirect_uri Parameter, a Client-controlled post-action redirect parameter, a Json Request Body. In CAVET terms, vectors are the application's perception system — the lenses through which it sees input. The same payload behaves differently depending on which lens it arrives through. A vector is a mechanism, not a payload. SVG is a vector; the payload you deliver through it is an exploit, and that belongs in the playbook that uses it — not in the library.",{"id":721,"title":638,"titles":722,"content":723,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#how-they-link",[91],"Vectors are rarely asset-wide. They are usually scoped inside the parent that produces them — the functionality or technology where the mechanism was observed: File Upload             (functionality)\n  └─ SVG                 (vector)\n\nGoogle Sign-in          (technology)\n  └─ Oauth redirect_uri Parameter (vector) Scoped matches rank higher in the engine. The more precisely a vector is anchored, the more trustworthy the suggestion it appears in.",{"id":725,"title":726,"titles":727,"content":728,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#record-the-endpoint","Record the endpoint",[91],"When you know where a vector was observed, record the endpoint on the link. Endpoints are how the engine decides whether two capabilities actually meet — a vector without one can still match, but any playbook with a co-location requirement will not.",{"id":730,"title":643,"titles":731,"content":732,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#library-hygiene",[91],"One mechanism per component. Split \"SVG with stored XSS\" into SVG (vector) and Stored XSS (gadget) — the playbook is where they combine.",{"id":734,"title":648,"titles":735,"content":736,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#in-the-app",[91],"Create one from Vectors with Add Vector: Name (required), Category (required), Description, and Tags. Vectors are usually observed rather than invented — you find an SVG file-type vector while mapping an uploader, then link it as a scoped child (CLV) of the component that produces it. Nest deeper with Nested Vectors, attach a quirk to a vector with Add CLVQ, and express variance with a playbook Category + Tag combination instead of naming every format (the File type + #archive-file pattern).",{"id":738,"title":337,"titles":739,"content":740,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fvectors#whats-next",[91],"Quirks — the behaviors that change what a vector can do.",{"id":96,"title":95,"titles":742,"content":743,"level":270},[],"Behavior that tips an attack — and why scoping quirks to their parent matters most.",{"id":745,"title":746,"titles":747,"content":748,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#what-a-quirk-is","What a quirk is",[95],"A quirk is behavior that changes an outcome: Input Reflection, Unsafe Prototype-Chain Lookup, CORS Origin Reflection, server-side extraction, Accepts Arbitrary URL Scheme. In CAVET terms, quirks are ground truth — not what should be true of the stack in theory, but what is true of this target as observed. Quirks rarely stand alone. They amplify, dampen, or gate what a vector can do — which is why the engine weighs specific vector\u002Fquirk pairings when it ranks suggestions, not just the presence of each one.",{"id":750,"title":638,"titles":751,"content":752,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#how-they-link",[95],"Usually scoped inside the component where the behavior was observed: Node.js          (technology)\n  └─ Unsafe Prototype-Chain Lookup      (quirk)\n\nPassword-Reset   (functionality)\n  └─ Rate Limiting       (quirk) A quirk scoped to its parent is far more valuable than the same quirk floating on the asset. It tells the engine exactly where the behavior lives, and it unlocks playbooks that require that pairing — playbooks that a flat quirk can never satisfy.",{"id":754,"title":755,"titles":756,"content":757,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#stateful-quirks","Stateful quirks",[95],"Some quirks are stateful: triggering them changes how the target behaves or the state it is in. Record the behavior you actually observed, with the state details that matter, rather than the generic label — the engine accounts for how a specific quirk pairs with a specific vector when scoring.",{"id":759,"title":643,"titles":760,"content":761,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#library-hygiene",[95],"Name the behavior, not the exploit. Unsafe Prototype-Chain Lookup is a quirk; \"RCE via prototype-chain lookup in lodash merge\" is a playbook.",{"id":763,"title":648,"titles":764,"content":765,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#in-the-app",[95],"Create one from Quirks with Add Quirk: Name (required), Category (required), a Stateful toggle (\"This quirk is stateful\" — or stateless), Description, and Tags. Statefulness is set here, at creation: stateful quirks carry a Present \u002F Absent state wherever they're linked, and their objectives carry the same state. Whether a quirk enables or mitigates is not set here — it's chosen per playbook link, because the same quirk can enable one attack and mitigate another. Link quirks scoped inside the component where they were observed (a CLQ on the technology): the scoping is what lets scoped playbook requirements be satisfied at all.",{"id":767,"title":337,"titles":768,"content":769,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fquirks#whats-next",[95],"See the library in context: Overview or the Glossary.",{"id":100,"title":99,"titles":771,"content":772,"level":270},[],"How components nest — asset-level observations versus scoped children.",{"id":774,"title":775,"titles":776,"content":777,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#why-scoping-exists","Why scoping exists",[99],"\"This asset reflects input\" and \"this specific search bar reflects input\" are different claims. The second one is worth more: it tells the engine where the behavior lives, lets it satisfy scoped requirements that a flat observation never could, and produces suggestions you can act on instead of guesses. Scoping is how you make the second claim. A scoped component is any component linked inside (or under) the parent component it was observed on, rather than floating on the asset. Currently, only gadgets, vectors, and quirks can be scoped — and that set is expected to change as the platform matures and evolves.",{"id":779,"title":780,"titles":781,"content":782,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#the-levels","The levels",[99],"LevelWhat it meansExampleAsset-Level Component (ALC)Observed directly on the assetNode.js, File UploadComponent-Level Vector (CLV)A vector inside a specific parent.zip inside File UploadComponent-Level Quirk (CLQ)A quirk inside a specific parentserver-side extraction inside File UploadQuirk on a vector (CLVQ)A quirk attached to a component-level vectorInput Reflection on Json Request BodyNested vector (CLVV)A vector inside another vectorVector chainingComponent-Level Gadget (CLG)A gadget nested inside a parentinnerHTML inside Handlebars",{"id":784,"title":785,"titles":786,"content":787,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#asset-level-component-alc","Asset-Level Component (ALC)",[99,780],"An asset-level component is linked directly to the asset — it is a property of the target itself, not an observation about one of its parts. Technologies and functionalities are almost always asset-level. The claim reads as \"the asset has Node.js\" or \"the asset has a File Upload.\" Asset-wide gadgets, vectors, and quirks exist too — you observed them, but not inside any particular parent. Link them flat when that is the truth. The rule of thumb: scope when you observed the relationship, not when you assume it. Hover a section header — Technologies, Functionalities, and so on — and click + (the tooltip reads Link Technologies). An empty section offers the same from its Link Technology button.\n  In the Link Technologies modal, search (Search technology...) and tick the entries you need — they collect in the Selected (N) rail.\n  Each selected entry expands: Endpoints (Optional) — each endpoint becomes its own instance — plus Version (Optional) for technologies, and State Polarity (Present \u002F Absent) for stateful quirks.\n  Click Link \u002F Link N. The rows appear in the section and the engine re-evaluates immediately.",{"id":789,"title":790,"titles":791,"content":792,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#component-level-vector-clv","Component-Level Vector (CLV)",[99,780],"A component-level vector is linked inside the parent it was observed on — .zip inside File Upload, an OAuth parameter inside the sign-in provider. The claim reads as \"the File Upload accepts .zip files.\" Scoped vectors satisfy scoped requirements and rank higher than a flat observation ever could. In the Components panel, click the parent's link row to expand it. Each occurrence renders as an instance — the Global bucket plus one row per endpoint.\n  Hover the parent row — it applies to any instance — or a specific instance row, and click Manage CLVs (the up\u002Fdown icon).\n  In the Link CLVs modal, pick the assignment under Assign to: Global or a specific endpoint. Opening from an instance row locks it to that instance.\n  Search (Search clvs...), tick the vectors, and click Save \u002F Save N. They nest under the parent in the instance you chose.",{"id":794,"title":795,"titles":796,"content":797,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#component-level-quirk-clq","Component-Level Quirk (CLQ)",[99,780],"A component-level quirk is linked inside the parent where the behavior was observed — server-side extraction inside File Upload. The claim reads as \"the File Upload extracts archives server-side.\" A scoped quirk can satisfy structured playbook requirements; the same quirk floating on the asset cannot. Expand the parent's link row and hover it — or hover the specific instance you mean.\n  Click Manage CLQs (the atom icon).\n  In the Link CLQs modal: choose the Assign to instance, search (Search clqs...), and tick the quirks.\n  Stateful quirks require Present \u002F Absent in the Selected rail — the save stays disabled (Polarity required) until every one is answered.\n  Click Save \u002F Save N — the quirks nest under the parent in the chosen instance.",{"id":799,"title":800,"titles":801,"content":802,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#quirk-on-a-vector-clvq","Quirk on a vector (CLVQ)",[99,780],"The narrowest scope: a quirk attached to a component-level vector rather than to its parent. The claim reads as \"the JSON request body is reflected in the response.\" Use it when the behavior belongs to the vector itself — it is what scoped requirements reach for when a quirk only matters on one mechanism. Expand the parent row down to the vector chip inside its instance.\n  Click the atom icon on the chip — the tooltip reads Add CLVQ.\n  In the Link CLVQ modal, search (Search clvq...) and pick a single quirk; stateful quirks ask for Present \u002F Absent.\n  Click Add CLVQ — the quirk renders as a nested row under the vector, with a polarity dot. Quirks are terminal: Remove CLVQ takes it off, and nothing nests beneath it.",{"id":804,"title":805,"titles":806,"content":807,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#nested-vector-clvv","Nested vector (CLVV)",[99,780],"A vector inside another vector — how chained input paths are recorded when one mechanism is reached through another. Both mechanisms matter to the attack, so both are part of the claim, and the nesting is one level deep. Expand the parent row to the vector chip inside its instance.\n  Click the cyan up\u002Fdown icon on the chip — the tooltip reads Add nested vector. It is disabled with No nested vectors available when there is nothing left to pick.\n  In the Link CLVV modal, search (Search clvv...) and pick one vector.\n  Click Add Nested Vector — the child renders under its parent vector. A nested vector cannot nest further; Remove CLVV takes it off.",{"id":809,"title":810,"titles":811,"content":812,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#component-level-gadget-clg","Component-Level Gadget (CLG)",[99,780],"A component-level gadget is linked inside the component that exposes it — innerHTML inside Handlebars. The claim reads as \"Handlebars renders through innerHTML.\" Gadgets scope under technologies, functionalities, and other gadgets — never under vectors or quirks — because a gadget exists because of the component that carries it. Expand the parent's link row — a technology, functionality, or gadget — and hover it, or hover the instance you mean.\n  Click Manage CLGs (the chain icon).\n  In the Link CLGs modal: choose the Assign to instance, search (Search clgs...), tick the gadgets, and click Save \u002F Save N.\n  On a gadget chip, Manage CLGVs \u002F Manage CLGQs attach vectors and quirks to that gadget. Nothing nests under a CLG itself. Shortcut: when linking a technology or functionality, the entry's CLGs (Optional) dropdown (Add a CLG...) adds a gadget to the Global bucket upfront.",{"id":814,"title":815,"titles":816,"content":817,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#how-to-read-a-scoped-link","How to read a scoped link",[99],"A scoped link is a sentence about its parent — say it out loud to check the scope: LinkReads asFile Upload → .zip (CLV)\"The File Upload accepts .zip files.\"File Upload → server-side extraction (CLQ)\"The File Upload extracts archives server-side.\"Json Request Body → Input Reflection (CLVQ)\"The JSON request body is reflected in the response.\"Handlebars → innerHTML (CLG)\"Handlebars renders through innerHTML.\" Playbook requirements read the same way, in the asking mood. A requirement for File Upload → .zip is the engine asking \"does the file upload accept zip files?\" — and a required server-side extraction on the same parent asks the follow-up question, \"does it extract them?\" Observed links state what is; required links state what should be confirmed. That pairing is the mental model behind the Zip Slip case study. Polarity adds the negation. An Absent requirement on a stateful quirk reads as \"the target does not exhibit this\" — satisfied only by a confirmed absence, never by silence.",{"id":819,"title":820,"titles":821,"content":822,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#the-exact-parent-rule","The exact-parent rule",[99],"Scoped matching is strict about parentage. A vector scoped inside one functionality does not satisfy a requirement for the same vector type inside a different functionality: File Upload → .zip            does NOT satisfy      Archive Creation → .zip This is deliberate. Scoping that ignored its parent would just be a slower way of writing a flat link. Structural claims match structural requirements — that is what makes them precise. Playbook requirements use the same levels, so what you observe and what a playbook demands speak the same language.",{"id":824,"title":825,"titles":826,"content":827,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#instances-the-same-component-multiple-places","Instances: the same component, multiple places",[99],"One asset can surface the same component more than once — three file uploads, two APIs, several endpoints running the same service. Each occurrence is an instance, and endpoints are recorded per instance rather than per component. This matters downstream: instances are what co-location reason about. \"File upload and SSRF fetcher on the same endpoint\" is a statement about instances, not about components in general — two capabilities that exist on an asset but never meet on the same endpoint are not a chain.",{"id":829,"title":830,"titles":831,"content":832,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#quirks-carry-roles","Quirks carry roles",[99],"A quirk's meaning is contextual, and the vault records it that way: Enabling or mitigating — the role is assigned per playbook, not on the component itself. The same quirk can enable one attack and mitigate another.Present or absent — stateful quirks record whether the target exhibits the behavior or explicitly does not. A confirmed absence is a result, and the right kind of absence can satisfy a requirement written as \"does not exhibit.\" Details live in Requirements.",{"id":834,"title":337,"titles":835,"content":836,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#whats-next",[99],"Authoring Guide — how scoped observations become playbook triggers.Notespaces and Endpoints — where links, instances, and endpoints live.",{"id":104,"title":103,"titles":838,"content":839,"level":270},[],"The two organizing layers — curated structure and flexible labels.",{"id":841,"title":842,"titles":843,"content":844,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#categories-structural-groupings","Categories: structural groupings",[103],"A category is a themed grouping of components — Authentication, File type, Web framework, DOM Sink. Categories are per component type: the Authentication category on a functionality has nothing to do with the same name on a technology. They are free text with suggestions: when you create or edit a component, the Category field (required) suggests values already used in that workspace, so the shared vocabulary settles naturally instead of fragmenting into near-duplicates.",{"id":846,"title":847,"titles":848,"content":849,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#why-categories-matter","Why categories matter",[103,842],"Categories are what make broad playbook requirements possible. A playbook can require any functionality in the Authentication category instead of naming Email & Password Login, Email & OTP Login, and OAuth Connect separately — and every component you categorize later is covered automatically. That is one of the highest-leverage tools in trigger design (see the Authoring Guide). When the engine matches a category assignment on an asset, it reports both the category that satisfied it and the specific component behind it.",{"id":851,"title":852,"titles":853,"content":854,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#tags-flexible-labels","Tags: flexible labels",[103],"Tags are lighter than categories. Any component type can carry them: they're entered as a comma-separated list in the create\u002Fedit drawer (archive-file, legacy, needs-review). Normalized and displayed uniformly — stored lowercase, shown as #tag.Searchable — tag:archive-file in the command center.Combinable with categories in playbooks — the Tag Combo field on a Category assignment narrows it: File type + #archive-file means in the category and tagged.",{"id":856,"title":857,"titles":858,"content":859,"level":444},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#why-tags-matter","Why tags matter",[103,852],"Tags absorb variance without multiplying playbooks. One #archive-file tag turns a single Vector requirement into coverage for ZIP, TAR, JAR, and every future archive format you tag. If two playbooks differ only by which specific component they name, that's the signal to collapse them into one and use a category + tag.",{"id":861,"title":862,"titles":863,"content":864,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#good-habits","Good habits",[103],"Reuse before inventing. Pick the suggested category; a vocabulary of twenty categories beats two hundred one-offs.Categories are nouns of structure; tags are modifiers. File type is a category; archive-file, legacy, wip are tags.Tag once, benefit everywhere. Tags travel with the component to every playbook assignment and every search.Don't tag what a category already says. #authentication on an Authentication functionality adds nothing.",{"id":866,"title":867,"titles":868,"content":869,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#where-they-surface","Where they surface",[103],"SurfaceCategoriesTagsComponent create\u002Fedit drawerCategory * fieldTags fieldPlaybook component linkingCategory \u002F Tag modes, Tag ComboTag mode, Tag Combo, tag childrenSearchcategory:tag:, !tag:Tables and notespace headersCategory chipsTag chips",{"id":871,"title":337,"titles":872,"content":873,"level":276},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#whats-next",[103],"Link Components to a Playbook — category and combo assignments in practice.Reactive Checklist and Probes — the other half of a component's notespace.",{"id":112,"title":10,"titles":875,"content":876,"level":270},[],"Where observations live, and the data that makes matches precise.",{"id":878,"title":879,"titles":880,"content":881,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#every-entity-has-a-notespace","Every entity has a notespace",[10],"Each asset, playbook, and component carries a notespace: one page where its links, notes, and history live. When you open a technology, you are seeing its notespace; when you open an asset, you are seeing the asset's. Notespaces make the model uniform. A component is not just a tag — it is a full record that assets can link to, that other components can nest inside, and that notes can accumulate against over time.",{"id":883,"title":884,"titles":885,"content":886,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#links-carry-the-context","Links carry the context",[10],"A link between an asset and a component is not just \"this asset has this technology.\" Each link can carry: Endpoints — where the capability was observed.Scoped children — gadgets, vectors, and quirks nested inside a specific parent component.Requirements — whether a playbook needs it, or just benefits from it.Yield metadata — when a capability was earned, which playbook granted it, and the endpoint it was discovered on.",{"id":888,"title":889,"titles":890,"content":891,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#instances","Instances",[10],"A component can occur more than once on an asset — three uploads, two APIs, several endpoints running the same service. Each occurrence is an instance, and endpoints are recorded per instance. Instances are what co-location reasons about: \"these two capabilities meet on the same endpoint\" is a statement about occurrences, not about components in general. Two capabilities that exist on an asset but never share an endpoint are not a chain.",{"id":893,"title":894,"titles":895,"content":896,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#why-endpoints-matter","Why endpoints matter",[10],"Endpoints are what turn a pile of components into a theory of the target. A .zip upload on the marketing site and a server-side extraction quirk on the internal API are both \"on example.com\" — but they only combine if they actually meet at the same endpoint. The engine uses endpoints for co-location: a rule can require that two capabilities occur on the same endpoint before it counts. The stricter the endpoint data you record, the more trustworthy the match. Recording endpoints is not optional busywork. A playbook whose primitives were never tied to matching endpoints will not match — and that is by design, because an exploit that assumes two things meet without evidence is a guess.",{"id":898,"title":170,"titles":899,"content":900,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#probes",[10],"Component notespaces carry probes — short, reusable notes about how to check for that component on a target. When a checklist prompt asks you to confirm a specific component, its probes are one click away, so the \"how would I even check this\" knowledge travels with the prompt instead of living in your head.",{"id":902,"title":337,"titles":903,"content":904,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Foverview#whats-next",[10],"Playbooks — the recipes that consume all of this.",{"id":116,"title":115,"titles":906,"content":907,"level":270},[],"The field dictionary — everything a link between the vault's entities can carry.",{"id":909,"title":910,"titles":911,"content":912,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#what-a-link-carries","What a link carries",[115],"The link is the primitive the whole vault is built on: an asset linked to a component, a playbook linked to a requirement, a primitive linked to what earned it. Every link can carry the metadata below. This page is the dictionary; for how each field behaves during matching, see Requirements.",{"id":914,"title":915,"titles":916,"content":917,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#scope","Scope",[115],"FieldValuesMeaningLevelasset-level or component-levelWhether the link sits directly on the asset or nested inside a parent component. See Scopes and Levels.Parenta componentFor scoped links: the exact parent the child was observed in. Scoped matching requires the exact parent.",{"id":919,"title":920,"titles":921,"content":922,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#assignment","Assignment",[115],"FieldValuesMeaningModeindividual, category, category + tagWhat the link points at. Categories and combos resolve live as the library grows.Tag comboa #tagFor category links: the tag members must also carry.EvaluationAny, AllFor category links: one member is enough, or every member is required (and grows with the category).RequirementRequired, OptionalPlaybook links only. Required is a hard gate; optional tunes confidence.",{"id":924,"title":925,"titles":926,"content":927,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#observation-data","Observation data",[115],"FieldApplies toMeaningEndpointsasset linksWhere the capability was observed. Each endpoint is a separate instance; Global means no endpoint was recorded.Versiontechnology linksThe version observed, e.g. 18.2.0. Playbook constraints check it; how strictly depends on the engine mode.State polaritystateful quirksPresent or Absent — what was actually observed about the behavior.Quirk impactplaybook quirk linksEnabling or Mitigating — the role this quirk plays in this playbook.",{"id":929,"title":552,"titles":930,"content":931,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#earned-capabilities",[115],"FieldMeansSourcemanual (you recorded it) or yield (a playbook granted it on success)Yielded byFor earned links: the playbook whose success granted the capabilityYield on successPlaybook links: mark this capability as an output of the playbookPrompt for endpointYield configuration: ask which endpoint the capability was demonstrated on when it's grantedCo-locationPlaybook links: count this requirement only where its endpoints meet the required primitive's endpoints",{"id":933,"title":934,"titles":935,"content":936,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#why-the-dictionary-matters","Why the dictionary matters",[115],"Two reasons the same fields keep showing up across the docs: Every observation is structured the same way. A component on an asset, a requirement on a playbook, a primitive earned through a chain — same primitive, same metadata. Learn the fields once.The engine reads only these fields. If you can't express it as metadata, the engine can't act on it — which is why the authoring discipline matters more than prose in a playbook body.",{"id":938,"title":337,"titles":939,"content":940,"level":276},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#whats-next",[115],"Requirements — how each field behaves during matching.Notespaces and Links — where links live.",{"id":41,"title":10,"titles":942,"content":943,"level":270},[],"How the method, the component taxonomy, and the vault's storage model fit together.",{"id":945,"title":946,"titles":947,"content":948,"level":276},"\u002Fthe-model#three-layers-one-model","Three layers, one model",[10],"Everything Nimbus Vault does is built on a single model, expressed in three layers: Methodology — how to think about a target: CAVET's Observe → Probe → Reason → Test workflow, the contextual-hacking mindset, and chain recognition as a way of seeing compound attacks.Components — the vocabulary: the five component types, their categories and tags, and the scopes that let observations nest inside their parents.Notespaces — storage: where observations live, what a link can carry (endpoints, instances, polarity, impact, versions), and how earned primitives extend an asset beyond what recon can find. The Nexus Engine reads this model; playbooks are written against it. Learn the model once and every other page — mapping, prompts, suggestions, chains — is a view of the same structure.",{"id":950,"title":472,"titles":951,"content":952,"level":276},"\u002Fthe-model#where-to-start",[10],"New to the ideas? Read The CAVET Method first.Ready to work? Start with Map an Asset and come back when a field name stops making sense.",{"id":127,"title":126,"titles":954,"content":955,"level":270},[],"How Nimbus Vault organizes the targets you are hacking on.",{"id":957,"title":958,"titles":959,"content":960,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#the-hierarchy","The hierarchy",[126],"Platform — where the program lives: a bug bounty platform, a VDP, a private engagement. One record per source of work.Program — a scope of testing published by an organization: the rules, the rewards, the boundary.Asset — one concrete thing you are testing: admin.example.com, an API endpoint, an Android app, a source checkout. You rarely test a \"program\" directly. Work happens on assets, so that is where observations, components, and suggestions live.",{"id":962,"title":963,"titles":964,"content":965,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#one-asset-one-focus","One asset, one focus",[126],"The model pushes you to keep assets concrete. \"The whole product\" is not an asset. api.example.com is. Concrete assets make the Nexus Engine's matching precise — and precision is what ranks a suggestion to the top. Assets can have children: an app with its API, a host with its services. Hierarchy lets a capability on a child (a vector inside an API) sharpen what the engine knows about the parent without duplicating records.",{"id":967,"title":968,"titles":969,"content":970,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#getting-assets-in","Getting assets in",[126],"Manual — create an asset and link components as you observe them. This is the map an asset loop.CSV import — bring in a target list you already maintain and start linking components to each row.",{"id":972,"title":973,"titles":974,"content":975,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#asset-types","Asset types",[126],"Web, API, Mobile iOS, Mobile Android, Desktop, Browser Extension, Cloud Infrastructure, Network\u002FVPN, Smart Contract, Hardware\u002FIoT, Source Code Repository — pick the closest fit, and Other for anything the list does not cover. The type is descriptive: it tells collaborators what kind of target they are looking at. One type is special: Wildcard. A wildcard asset is a grouping container, not a tracked target — its name must be a pattern like *.example.com, and concrete URLs live beneath it as Web assets. It organizes a broad scope without pretending the wildcard itself is something you test.",{"id":977,"title":978,"titles":979,"content":980,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#sharing","Sharing",[126],"Individual assets can be shared outside the workspace with a link — useful when you want a second pair of eyes on one target without inviting someone into everything.",{"id":982,"title":337,"titles":983,"content":984,"level":276},"\u002Fworkspace\u002Fplatforms-programs-assets#whats-next",[126],"Learn the vocabulary you will attach to every asset: components.",{"id":131,"title":130,"titles":986,"content":987,"level":270},[],"Turn a target into a structured component inventory — click by click. Mapping is the highest-leverage habit in Nimbus Vault. Everything the engine can ever tell you is bounded by what you record. This page is the operational loop; Scopes and Levels explains the model behind it.",{"id":989,"title":990,"titles":991,"content":992,"level":276},"\u002Fworkspace\u002Fmap-an-asset#where-mapping-happens","Where mapping happens",[130],"Open the asset (via its program, or Programs → Assets), and switch the right-hand sidebar to the Components panel. That panel is the inventory: one section per component type, each holding the things you have observed.",{"id":994,"title":995,"titles":996,"content":997,"level":276},"\u002Fworkspace\u002Fmap-an-asset#the-linking-flow","The linking flow",[130],"Hover a section header and click + (e.g. Link Technologies), or use the empty-state button for a type (Link Technology).\n  In the modal, search the section's list. Components already linked to this asset are excluded, so what you see is what's missing. Tick entries — they collect in the Selected (N) rail.\n  Each selected entry expands its metadata:Endpoints (Optional) — the concrete paths where you observed it. Type a path, press Add endpoint; a leading \u002F is added for you, duplicates are ignored. Each endpoint becomes its own instance.Version (Optional) — technologies only, e.g. 18.2.0.State Polarity — stateful quirks only: Present or Absent.CLQs \u002F CLGs \u002F CLVs (Optional) — attach scoped children right here (Add a CLQ...), including nested CLVVs and CLVQs.\n  Confirm with Link \u002F Link N. The engine re-evaluates immediately — suggestions and prompts update on the spot.",{"id":999,"title":1000,"titles":1001,"content":1002,"level":276},"\u002Fworkspace\u002Fmap-an-asset#scope-it-correctly","Scope it correctly",[130],"The level you link at changes what the engine can do with it: Direct on the asset — for observations that belong to the whole target.Scoped inside a parent — a vector inside the file upload that produces it, a quirk inside the technology where you saw the behavior. Scoped requirements demand the exact parent (why).Nested deeper — vector inside vector, quirk on a vector: each scoped level has its own link modal (Link CLQs, Link CLVs, ...) with an Assign to choice: Global — or a specific endpoint, tying the child to one instance.",{"id":1004,"title":1005,"titles":1006,"content":1007,"level":276},"\u002Fworkspace\u002Fmap-an-asset#technology-defaults","Technology defaults",[130],"If a technology carries defaults — common quirks, vectors, or gadgets defined in its notespace — they surface when you link it, governed by the default's Inheritance Level (Asset or Component) and Inheritance Mode (Auto or Manual). Confirm what applies instead of retyping the stack's usual suspects.",{"id":1009,"title":1010,"titles":1011,"content":1012,"level":276},"\u002Fworkspace\u002Fmap-an-asset#habits-that-pay","Habits that pay",[130],"Technologies and functionalities first. They define the possibility space; vectors, quirks, and gadgets get linked onto the things that produce them.Endpoints are half the value. A capability without an endpoint can still match — but co-location requirements, the ones that keep chains honest, need them.One sitting beats five. The value is in completeness; a half-mapped asset yields half-trustworthy suggestions.Not sure of the exact value? Link what you can confirm now; resolve the specifics when a prompt asks. If a submit stays disabled, the rail shows why — State polarity required, CLVQ targets a vector that is not linked, and similar messages name the missing field.",{"id":1014,"title":337,"titles":1015,"content":1016,"level":276},"\u002Fworkspace\u002Fmap-an-asset#whats-next",[130],"The engine now has something to work with: work the prompts it generates.",{"id":135,"title":134,"titles":1018,"content":1019,"level":270},[],"Platforms, programs, and assets — the exact forms, in order. Everything in the vault hangs off one hierarchy: platform → program → asset. Set it up once, properly, and every later step inherits the structure.",{"id":1021,"title":1022,"titles":1023,"content":1024,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#_1-create-a-platform","1. Create a platform",[134],"A platform is where the work comes from: a bug bounty platform, a VDP, a private client. Open Platforms in the sidebar.Click Add Platform.Fill in the drawer: FieldRequiredNotesNameYese.g. HackerOne, Private clientsDescriptionNoShort descriptionTagsNoComma-separated, e.g. bug bounty, privateCurrencyNoe.g. USD — shown alongside rewardsWebsiteNoe.g. example.comLogo URLNoOptional branding Click Create Platform. Platforms in the list can be favorited — the star on each row (Favorite platform \u002F Unfavorite platform) keeps active sources at hand.",{"id":1026,"title":1027,"titles":1028,"content":1029,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#_2-create-a-program","2. Create a program",[134],"A program is one organization's scope — where the rules of engagement live. Open the platform (or go to Programs and click Add Program).Fill in the drawer: FieldRequiredNotesNameYesThe organization's program namePlatformNoPre-filled when launched from inside a platformProgram TypeNoBug Bounty, VDP, or PentestStatusNoActive, Paused, or Ended — defaults to ActiveLaunch DateNoWhen the program startedProgram URLNoLink to the official briefRewards RangeNoFree text, e.g. $100 - $10,000Logo URLNoOptional branding Click Create Program. The program's page carries its own guidelines editor — paste the scope, excluded assets, and program rules there; save from that page. It is the one place to re-read the rules without leaving the vault.",{"id":1031,"title":1032,"titles":1033,"content":1034,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#_3-create-assets","3. Create assets",[134],"Assets are the concrete things you test. There's a global Assets page, and asset lists inside programs. Click Add Asset.Fill in the drawer: FieldRequiredNotesNameYese.g. api.example.com; the placeholder follows the chosen typeAsset TypeYesPick from the type list (Web, API, Mobile iOS\u002FAndroid, Desktop, Cloud Infrastructure, Network\u002FVPN, Smart Contract, Hardware\u002FIoT, Source Code Repository, and more)PriorityNoDefaults to None; also Low, Medium, High, CriticalTagsNoComma-separated, e.g. prod, internal, mobileURLNoA direct link to the target Click Create Asset.",{"id":1036,"title":1037,"titles":1038,"content":1039,"level":444},"\u002Fworkspace\u002Fmanage-your-scope#wildcards-are-containers-not-targets","Wildcards are containers, not targets",[134,1032],"Choose the Wildcard type when you want to organize a broad scope. Two rules apply: The name must contain * — e.g. *.example.com or target.*.staging.com. Otherwise the drawer refuses it: \"Wildcard names must contain *.\"Concrete URLs live under the wildcard as Web assets — a URL whose parent wildcard does not exist is rejected. A wildcard groups; it is never the thing you map.",{"id":1041,"title":1042,"titles":1043,"content":1044,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#bring-in-a-list-you-already-have","Bring in a list you already have",[134],"If you maintain targets elsewhere, skip the retyping: Open the Assets page and click Import.The Import Assets modal parses your list; review and select the rows to bring in.Click Import N assets — progress streams as they land, and the import can be cancelled mid-run. Import first, then map the ones worth pursuing. Coming from HackerOne? The program's scope exports as a CSV — drop that file straight into the Import Assets modal (the drop zone is built for it; .csv, .tsv, and .txt are accepted, up to 10 MB). The file is parsed in your browser and never leaves the page; after you review the rows — ones that already exist are flagged as duplicates — only the normalized assets are sent to your workspace.",{"id":1046,"title":1047,"titles":1048,"content":1049,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#habits-that-pay-off","Habits that pay off",[134],"Concrete names. api.example.com beats \"the API\" — precision starts with what you called things.Priorities are triage. Map everything if you like; priority decides what gets attention first.Nest what belongs together. Subdomains under their domain, an API under its app — a capability on a child sharpens what the engine knows about the parent.One workspace per context — client boundaries are worth preserving, and cloning makes the setup cheap.",{"id":1051,"title":337,"titles":1052,"content":1053,"level":276},"\u002Fworkspace\u002Fmanage-your-scope#whats-next",[134],"With the scope in place, the real work starts: map an asset.",{"id":139,"title":138,"titles":1055,"content":1056,"level":270},[],"Invite teammates, share single entities, and keep a visible trail.",{"id":1058,"title":1059,"titles":1060,"content":1061,"level":276},"\u002Fworkspace\u002Fshare-and-collaborate#working-in-a-shared-workspace","Working in a shared workspace",[138],"A workspace is built to be shared. The value compounds when the mapping, the library, and the outcomes are everyone's — one person's observation unlocks another person's suggestion.",{"id":1063,"title":355,"titles":1064,"content":1065,"level":444},"\u002Fworkspace\u002Fshare-and-collaborate#members-and-roles",[138,1059],"Invite teammates from workspace settings by email — or share the workspace invite link, which lets anyone holding it join. Each invite carries a role: Admin — manages workspace settings, members, and everything inside.Member — full access to the vault's content. Invites have an expiry and a status (pending, accepted, declined, revoked, expired), and pending invites are visible from your sidebar avatar, so you always know who has not joined yet. Admins can also review activity in the workspace's audit log.",{"id":1067,"title":1068,"titles":1069,"content":1070,"level":444},"\u002Fworkspace\u002Fshare-and-collaborate#what-sharing-looks-like-in-practice","What sharing looks like in practice",[138,1059],"The library is the team's memory. A component mapped by one hunter is available to everyone's assets.Playbooks are institutional knowledge. Outcomes and yields accumulate against a shared threat library.Suggestions are personal where it matters. Your assets and your hunt stay yours; the knowledge underneath is shared.",{"id":1072,"title":1073,"titles":1074,"content":1075,"level":276},"\u002Fworkspace\u002Fshare-and-collaborate#sharing-a-single-entity","Sharing a single entity",[138],"Sometimes you want a second pair of eyes without inviting someone into everything. Any entity — an asset, a playbook, a component — can be shared as a link: The link opens a read-only snapshot: notes, links, and structure as they were shared.Recipients authenticate if they are not signed in, then land back on the snapshot.Snapshots can carry an expiry, so links are not forever. This is the \"show, don't invite\" path: useful for triage opinions, client reviews, or handing off context around a single finding.",{"id":1077,"title":1078,"titles":1079,"content":1080,"level":276},"\u002Fworkspace\u002Fshare-and-collaborate#keeping-it-healthy","Keeping it healthy",[138],"Give roles deliberately. Admin is for the people who should change settings and membership.Share knowledge, not just assets. The compounding only works when observations land in the shared library.Use expiry on snapshot links for anything client-facing.",{"id":1082,"title":337,"titles":1083,"content":1084,"level":276},"\u002Fworkspace\u002Fshare-and-collaborate#whats-next",[138],"Clone a Workspace — start the next engagement from a known-good setup.Account and Workspaces — roles and plan basics.",{"id":143,"title":142,"titles":1086,"content":1087,"level":270},[],"Start an engagement from your best setup instead of an empty vault.",{"id":1089,"title":1090,"titles":1091,"content":1092,"level":276},"\u002Fworkspace\u002Fclone-a-workspace#why-clone","Why clone",[142],"A tuned vault — the component library you trust, the playbooks that actually fire, a scope structure that matches how you work — is a head start. Cloning copies it into a fresh workspace so the next engagement begins from your best state, not from zero.",{"id":1094,"title":1095,"titles":1096,"content":1097,"level":276},"\u002Fworkspace\u002Fclone-a-workspace#what-you-can-take-with-you","What you can take with you",[142],"Open Workspace Settings → Clone Workspace. You choose which parts come along: Programs & Assets — platforms, programs, assets, and their notes and observations.Components — the component library.Playbooks — the threat library, with requirements and yields. All three are selected by default; deselect what you don't need. Cross-references are handled for you: if a cloned link points at something you did not select, the reference is pruned cleanly — never left dangling, never silently pulling in things you excluded. The whole clone runs as a single operation, so a half-cloned workspace cannot happen.",{"id":1099,"title":1100,"titles":1101,"content":1102,"level":276},"\u002Fworkspace\u002Fclone-a-workspace#when-to-clone","When to clone",[142],"New engagement, same playbook. Keep the library and the team's playbooks; bring a fresh scope.Client templates. Maintain a well-curated base workspace and branch it per client.Experiments. Duplicate before a big restructure; the original is untouched. Cloning creates a new workspace, so your plan's workspace ownership limit applies — Free accounts own one workspace, Pro accounts up to five. See Account and Workspaces.",{"id":1104,"title":337,"titles":1105,"content":1106,"level":276},"\u002Fworkspace\u002Fclone-a-workspace#whats-next",[142],"Manage Your Scope — shape the fresh clone.Share and Collaborate — bring the team in.",{"id":120,"title":10,"titles":1108,"content":1109,"level":270},[],"Your scope, your team, and how work is organized.",{"id":1111,"title":1112,"titles":1113,"content":1114,"level":276},"\u002Fworkspace#the-container-for-everything","The container for everything",[10],"A workspace holds your target inventory, component library, playbooks, and notespaces — and it's what you share with a team. This section covers everything around the hunt itself: Platforms, Programs, and Assets — the scope hierarchy everything hangs off.Map an Asset — turn a target into a structured component inventory (the core operating loop).Manage Your Scope — create platforms, programs, and assets; wildcard containers; imports.Share and Collaborate — members, roles, invite links, and snapshot sharing.Clone a Workspace — start the next engagement from your best setup.",{"id":1116,"title":1117,"titles":1118,"content":1119,"level":276},"\u002Fworkspace#where-work-starts","Where work starts",[10],"If you're new: create your scope first (Manage Your Scope), then map an asset and let the engine take it from there.",{"id":154,"title":153,"titles":1121,"content":1122,"level":270},[],"How matches become ranked, explainable suggestions you can act on.",{"id":1124,"title":1125,"titles":1126,"content":1127,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#the-moment-a-match-happens","The moment a match happens",[153],"Every time an asset changes — a component is linked, an endpoint recorded, a prompt resolved — the engine re-evaluates the playbook library against it. A playbook appears as a suggestion only when every required component is satisfied. No partial credit, no \"close enough.\" The result is deterministic: the same library and the same asset always produce the same suggestions in the same order. Nothing is guessed, and nothing changes until the data changes.",{"id":1129,"title":1130,"titles":1131,"content":1132,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#ranked-and-explainable","Ranked and explainable",[153],"Suggestions are sorted best-first, and every suggestion can explain itself. Open one and you see the components that matched, how specific each match was, and what the playbook produces if it succeeds. The reasoning is the point — if a match looks wrong, the fix is in your data, and the suggestion list will follow.",{"id":1134,"title":1135,"titles":1136,"content":1137,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#what-ranks-a-suggestion-higher","What ranks a suggestion higher",[153],"Ranking reflects specificity and completeness, not just \"how many things matched\": Structure beats volume. A quirk scoped inside the exact technology that owns it is a stronger claim than the same quirk floating somewhere on the asset. Scoped matches outrank flat ones.Category precision. A category + tag requirement is satisfied by fewer things than a bare category — and fires only when the exact subset exists.Endpoint support. A requirement that asks for capabilities to meet on the same endpoint only ranks well when the endpoints actually line up.Quirk pressure. Enabling quirks raise confidence; mitigating quirks lower it. Mitigations weigh heavier in the other direction — one confirmed mitigation can block an exploit, so its absence is treated as more meaningful than a single enabler's presence.Version confidence. With lax version matching an unverified version slightly lowers confidence; with strict matching it removes the candidate entirely. The engine never inflates relevance. If a suggestion is at the top, it is because the evidence you recorded supports it.",{"id":1139,"title":1140,"titles":1141,"content":1142,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#partially-satisfied-playbooks","Partially satisfied playbooks",[153],"A playbook whose requirements are partially satisfied does not appear as a weak suggestion — it becomes work. Its missing required components turn into proactive prompts on the asset, ordered by how close they are to unlocking something. That split is deliberate. Suggestions are for playbooks you can act on now; prompts are for the gap between where you are and the next suggestion.",{"id":1144,"title":399,"titles":1145,"content":1146,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#reading-a-suggestion",[153],"The match — which of the playbook's requirements were satisfied, and at what level.The confidence — how specific and complete the evidence is.The yield — the capability the playbook grants if it succeeds, which can satisfy a downstream playbook's requirement (see Yields and Primitives). From here, the loop is run it and record what happened.",{"id":1148,"title":337,"titles":1149,"content":1150,"level":276},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#whats-next",[153],"Checklist and Probes — the other half: what the engine asks you to look for.Requirements — the mechanics behind every match.",{"id":163,"title":162,"titles":1152,"content":1153,"level":270},[],"Prompts for what is still unknown — how the engine turns near-misses into questions.",{"id":1155,"title":1156,"titles":1157,"content":1158,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#reactive-vs-proactive","Reactive vs. proactive",[162],"Matching is reactive: it answers questions about what you have already recorded. The proactive checklist is the other half: it asks what is still unknown. For every asset, the engine generates prompts from playbook requirements that are not yet confirmed. Each item is a question about the target: Does this asset expose a password-reset flow?",{"id":1160,"title":1161,"titles":1162,"content":1163,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#where-prompts-come-from","Where prompts come from",[162],"A prompt exists because a playbook is a near-miss: some of its required components are present on the asset, but not all. The engine is telling you \"this playbook is one confirmation away\" — the missing required components become the prompts, ordered by how close they are to unlocking something. Required CLQs are the most common source: a condition that is necessary for an attack to be applicable, and easy to forget to check — \"does the server extract uploaded archives?\" — is exactly the sort of thing worth a standing question.",{"id":1165,"title":1166,"titles":1167,"content":1168,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#resolving-a-prompt","Resolving a prompt",[162],"Three honest answers, three different mechanics: Yes — link the missing component to the asset. The prompt disappears on its own — satisfied requirements don't linger — and the playbook fires immediately if nothing else is missing. No history entry is created for a prompt that resolved itself.No — only after tracing the full surface. Record the answer as a manual check; the prompt moves to the asset's history and won't be suggested again unless you remove it there. A wrong negative silently suppresses every playbook behind it.Endpoint — if confirming the capability revealed where it lives, record the endpoint on the link. Prompts that ask about a component with probes carry a probe-count badge — the context menu's View probes shows exactly how to check for it without leaving the asset.",{"id":1170,"title":1171,"titles":1172,"content":1173,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#what-happens-after-you-resolve","What happens after you resolve",[162],"The engine re-evaluates the asset immediately: new suggestions appear, others disappear, and the checklist shrinks. Every resolution either unlocks a playbook or prunes the search space — which is why working the checklist is the fastest way to make the vault smarter. Resolutions land in the asset's History → Checklists → Proactive Checks, alongside the reactive checks.",{"id":1175,"title":1176,"titles":1177,"content":1178,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#checklist-vs-coverage","Checklist vs. coverage",[162],"The checklist is the open work for one asset; coverage measures how much of what could apply you have confirmed. Both live on the asset, and both move when you resolve prompts with evidence. See Dashboard Metrics.",{"id":1180,"title":337,"titles":1181,"content":1182,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#whats-next",[162],"Work a Prompt — the practical discipline.Reactive Checklist — the objectives side of the same panel.",{"id":167,"title":166,"titles":1184,"content":1185,"level":270},[],"The objectives your components carry — authored once, checked on every target.",{"id":1187,"title":1188,"titles":1189,"content":1190,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#objectives-a-components-test-list","Objectives: a component's test list",[166],"The reactive checklist is built from objectives — the concrete things worth checking whenever a component shows up on a target. For a file upload, an objective might be \"Test for unrestricted file type acceptance\". Objectives are authored on the component, in its Checklists tab: Open the component and switch to Checklists.Click Add Objective.Fill in the Objective title and an optional Description (supports lists, inline code, and headings for context, links, or examples). For bulk entry, switch to Paste multiple — one objective per line becomes one objective each. Objectives can be drag-reordered, and the order is shared across every asset the component appears on. For stateful quirks, each objective also carries a State: Present or Absent — and the panel filters by the same values, so a quirk's test list stays coherent with how the quirk actually behaves.",{"id":1192,"title":1193,"titles":1194,"content":1195,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#where-objectives-surface","Where objectives surface",[166],"They travel with the component. When it's linked to an asset, its objectives appear in that asset's Suggestions → Checklists → Reactive section — the checklist for what you can check, as opposed to the proactive side, which asks for what's missing.",{"id":1197,"title":1198,"titles":1199,"content":1200,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#checking-them-off","Checking them off",[166],"Check an objective once you have verified it on the asset. The check is recorded in the asset's History → Checklists → Reactive Checks — the durable record of what was verified, on this asset, by hand. Entries stay in history until you remove them. Removing one makes it eligible to surface again. That's the escape hatch for mistakes, not the default — the record is meant to be trustworthy.",{"id":1202,"title":1203,"titles":1204,"content":1205,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#why-objectives-matter","Why objectives matter",[166],"They make component knowledge actionable. An objective is what a colleague — or future you — actually does with the component on a new target.They compound. Write the test once on the component, and every asset it ever appears on inherits it.They discipline review. A checklist beats trying to remember what mattered last time.",{"id":1207,"title":337,"titles":1208,"content":1209,"level":276},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#whats-next",[166],"Work a Prompt — working both checklist sides in practice.Probes — the how-to notes that make each check concrete.",{"id":171,"title":170,"titles":1211,"content":1212,"level":270},[],"Reusable how-to-check notes that surface at the moment a prompt asks.",{"id":1214,"title":1215,"titles":1216,"content":1217,"level":276},"\u002Fnexus-engine\u002Fprobes#what-a-probe-is","What a probe is",[170],"If objectives say what to check, probes answer how. A probe is a short, reusable note attached to a component: the query to send, the UI path to follow, the thing that took you an hour to figure out the first time. Probes live on the component, in its Probes tab: Open the component and switch to Probes.Click Add Probe.Fill in the title and an optional description. They support drag-reordering, editing, and deletion — the same conventions as objectives.",{"id":1219,"title":1220,"titles":1221,"content":1222,"level":276},"\u002Fnexus-engine\u002Fprobes#where-probes-surface","Where probes surface",[170],"At the moment of need. When a proactive prompt asks you to confirm a component on an asset, the prompt carries a probe-count badge — and its context menu offers View probes, opening that component's probes as a numbered list, right there in the asset view. If the component has no probes yet, the panel says so: \"This component has no probes defined in its notespace yet.\"",{"id":1224,"title":1225,"titles":1226,"content":1227,"level":276},"\u002Fnexus-engine\u002Fprobes#why-probes-matter","Why probes matter",[170],"They close the distance between noticing and checking. A checklist only accelerates you if the how is one click away.They capture hard-won knowledge. The bypass that worked, the header that mattered — written once, surfaced forever.They compound like everything else. A good probe serves every asset the component ever appears on, and every teammate who ever works it.",{"id":1229,"title":337,"titles":1230,"content":1231,"level":276},"\u002Fnexus-engine\u002Fprobes#whats-next",[170],"Proactive Checklist — where probes surface.Work a Prompt — the practice of resolving prompts with evidence.",{"id":175,"title":174,"titles":1233,"content":1234,"level":270},[],"Resolve the checklist accurately — where it lives, and what each action does.",{"id":1236,"title":1237,"titles":1238,"content":1239,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#where-prompts-live","Where prompts live",[174],"Open an asset and switch to Suggestions → Checklists. The panel has two sections: Proactive — near-miss prompts. A playbook is partially satisfied and the engine is asking about a missing required component. Empty state: \"No near-miss prompts right now.\"Reactive — the objectives carried by components linked to this asset (what objectives are).",{"id":1241,"title":1242,"titles":1243,"content":1244,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#resolving-a-proactive-prompt","Resolving a proactive prompt",[174],"A prompt is a question: does this capability apply here? Three honest answers, three different mechanics: Assign the missing component to the asset (the linking flow). The prompt disappears on its own — satisfied requirements don't linger — and the playbook fires immediately if nothing else is missing. No history entry is created for a prompt that resolved itself.\n  A negative is a real result, but only after you have traced the whole flow: the parent, the child, and the interaction between them. Incomplete negatives silently suppress every playbook behind them. Record the answer as a manual check — the prompt moves to the asset's history and won't be suggested again unless you remove it there.\n  Prompts that ask about a component with probes carry a probe-count badge. Open the prompt's context menu → View probes to see exactly how to check for it, without leaving the asset.",{"id":1246,"title":1247,"titles":1248,"content":1249,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#working-the-reactive-objectives","Working the reactive objectives",[174],"Objectives arrive with the components you link, so they are always relevant to what you mapped. Check them off as you verify them in the app — each check is recorded in the asset's history under Reactive Checks. This list is what the Playbook Coverage Rate measures.",{"id":1251,"title":1252,"titles":1253,"content":1254,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#where-the-record-goes","Where the record goes",[174],"Open the asset's History panel: Playbooks — outcome history for playbook runs.Checklists — Proactive Checks (manual prompt resolutions) and Reactive Checks (objective check-offs). Entries stay until you remove them. Removing an entry makes it eligible again — a prompt can ask once more, an objective can resurface. That is the escape hatch for mistakes, not the default: the record is meant to be trustworthy. Never resolve a prompt from assumption. The checklist exists to capture evidence — treating it as a click-through form defeats the entire model, because everything downstream (suggestions, scores, chains) reasons from what it says.",{"id":1256,"title":1171,"titles":1257,"content":1258,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#what-happens-after-you-resolve",[174],"The engine re-evaluates the asset immediately: new suggestions appear, others disappear, the remaining checklist shrinks. Resolutions are revision-safe — update the record whenever you learn something new; the engine follows your data, not a stale decision.",{"id":1260,"title":337,"titles":1261,"content":1262,"level":276},"\u002Fnexus-engine\u002Fwork-a-prompt#whats-next",[174],"When a suggestion looks right, go execute: run a playbook.",{"id":147,"title":10,"titles":1264,"content":1265,"level":270},[],"Deterministic matching, ranked suggestions, and the proactive checklist.",{"id":1267,"title":1268,"titles":1269,"content":1270,"level":276},"\u002Fnexus-engine#rules-not-guesses","Rules, not guesses",[10],"The Nexus Engine is deterministic. Given the same library and the same asset, it always produces the same suggestions in the same order. There is no model making up plausible-sounding attacks — every suggestion traces back to a playbook and the exact components that satisfied it. That property is what makes the output trustworthy: you can audit it, and you can fix it by fixing your data.",{"id":1272,"title":1273,"titles":1274,"content":1275,"level":276},"\u002Fnexus-engine#in-this-section","In this section",[10],"Suggestions and Ranking — how matches become ranked, explainable suggestions.Proactive Checklist — prompts for what is still unknown.Reactive Checklist — the objectives your components carry.Probes — reusable how-to-check notes that surface with prompts.Work a Prompt — the practical discipline for both checklist sides.",{"id":1277,"title":1278,"titles":1279,"content":1280,"level":276},"\u002Fnexus-engine#how-a-match-happens","How a match happens",[10],"Every time an asset changes, the engine re-evaluates the playbook library against it: Hard gates — playbooks are checked against the asset's components. A missing required component excludes the playbook — no exceptions, no partial credit.Structure matters — a quirk scoped inside a specific technology is not the same as the same quirk anywhere on the asset. Scoped matches are stronger and rank higher.Co-location — where a playbook demands it, requirements must be tied to intersecting endpoints.Ranking — satisfied playbooks are scored by how specific and complete the match is. The most precise, best-supported suggestion sits at the top.Coverage — the engine also measures how much of what could apply you have actually confirmed.",{"id":1282,"title":1283,"titles":1284,"content":1285,"level":276},"\u002Fnexus-engine#the-proactive-checklist","The proactive checklist",[10],"Matching is reactive: it answers questions about what you already recorded. The checklist is proactive: it asks what is still unknown. For each asset, the engine generates prompts — questions whose answers would unlock more playbooks. Resolving a prompt with evidence updates the asset and triggers a fresh round of matching. A negative answer is a real result, but it must come from checking the full surface: a wrong \"no\" silently suppresses every playbook behind it. See Proactive Checklist for the model and Work a Prompt for the practice.",{"id":1287,"title":1288,"titles":1289,"content":1290,"level":276},"\u002Fnexus-engine#why-it-compounds","Why it compounds",[10],"The engine is not a scanner. It does not know more than you tell it — it knows better than a note pile. Every confirmed component and every consumed prompt sharpens the next suggestion, and earned primitives let later playbooks stand on earlier successes.",{"id":1292,"title":337,"titles":1293,"content":1294,"level":276},"\u002Fnexus-engine#whats-next",[10],"Put it to work: map an asset, then work a prompt.",{"id":186,"title":185,"titles":1296,"content":1297,"level":270},[],"From the Add Playbook drawer to a saved recipe — the exact steps.",{"id":1299,"title":1300,"titles":1301,"content":1302,"level":276},"\u002Fplaybooks\u002Fcreate-a-playbook#create-it","Create it",[185],"Open Playbooks in the sidebar.Click Add Playbook — in the toolbar, or the button in the empty state.Fill in the drawer: FieldRequiredNotesNameYesThe playbook's title, e.g. Zip Slip — Arbitrary File Write via Archive Extraction. Must be unique in the workspace.DifficultyNoN\u002FA or 1–10 — how hard it is to execute.SeverityNoN\u002FA, Low, Medium, High, or Critical — the impact if it lands.TagsNoComma-separated, e.g. archive, file-upload, rce.ReferencesNoComma-separated links — the research this playbook came from. Click Create Playbook. The playbook appears in the list (a toast confirms it); open it by clicking its card. Name collisions are rejected — you will get \"A playbook with that name already exists in this workspace.\" Rename one of them, or merge them (near-duplicates are usually a tagging problem — see the Authoring Guide).",{"id":1304,"title":1305,"titles":1306,"content":1307,"level":276},"\u002Fplaybooks\u002Fcreate-a-playbook#write-the-body","Write the body",[185],"Open the playbook to land in its notespace. The left side is the notes editor with a Rich editor \u002F Raw markdown toggle, a save-state indicator (Unsaved, Draft, Saved), and Save (⌘S). This is where everything that isn't a trigger condition belongs. The Authoring Guide makes the split explicit: requirements define when the playbook fires; the body tells the hunter what to do once it does. A body that works well in practice usually covers: What this achieves — one line, so a hunter in a hurry gets it instantly.Preconditions as observed — what the mapped context means, in plain words.Execution steps — numbered, with the payloads and variant techniques that would bloat the requirements.Bypass notes — WAF tricks, encoding variants, language-specific gotchas.References — deeper reading for the unlucky-run case.",{"id":1309,"title":1310,"titles":1311,"content":1312,"level":276},"\u002Fplaybooks\u002Fcreate-a-playbook#the-rest-of-the-notespace","The rest of the notespace",[185],"The sidebar holds the panels that make the playbook executable: Components — the requirements. Built on the next page: Link Components to a Playbook.Yields — what the playbook produces on success: Declare Yields.Folder — supplementary notes attached to the playbook.Info — severity, difficulty, tags, references, and creation\u002Fupdate history.",{"id":1314,"title":1315,"titles":1316,"content":1317,"level":276},"\u002Fplaybooks\u002Fcreate-a-playbook#managing-a-playbook","Managing a playbook",[185],"Edit fields — the pencil on the playbook card reopens the drawer as Edit Playbook (Save Playbook).Delete — Delete playbook on the card.Share — Share this playbook in the notespace header copies a read-only snapshot link (see Share and Collaborate).",{"id":1319,"title":337,"titles":1320,"content":1321,"level":276},"\u002Fplaybooks\u002Fcreate-a-playbook#whats-next",[185],"Link Components to a Playbook — turn the body into a firing trigger.Declare Yields — let the playbook unlock others when it succeeds.",{"id":190,"title":189,"titles":1323,"content":1324,"level":270},[],"Build the trigger — modes, required\u002Foptional, scoping, and every field on the way.",{"id":1326,"title":1327,"titles":1328,"content":1329,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#the-flow","The flow",[189],"Open the playbook and go to its Components panel.Click Link Component (panel header), the hover Add Component on a section, or Link a Component in the empty state.In the Link Components modal, pick an assignment mode: Individual, Category, or Tag. (Category and Tag hide the Quirks type.)Pick a component type chip — Technologies, Functionalities, Gadgets, Primitives, Vectors, Quirks — and search the list.Tick rows; the Selected (N) rail collects them. Confirm with Link \u002F Link N. Every selected entry then expands its metadata, under Assignment & Details (Individual) or Assignment (Category\u002FTag). This is where the trigger is really designed.",{"id":1331,"title":1332,"titles":1333,"content":1334,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#requirement-required-or-optional","Requirement: Required or Optional",[189],"This single toggle is the most consequential field on the page: Required — a hard gate. The engine excludes the playbook until this is satisfied. Missing required pieces become proactive prompts on the asset.Optional — a confidence signal. The playbook fires without it; presence raises the score, absence lowers it. If a component matters but can't reliably be confirmed in black-box testing, make it Optional — a required condition that can never be confirmed produces silence, not precision. See the Authoring Guide.",{"id":1336,"title":1337,"titles":1338,"content":1339,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#category-and-tag-modes","Category and Tag modes",[189],"Instead of naming one component, a Category assignment covers any member of a category — and a Tag narrows within it: Evaluation Mode: Any \u002F All — Any needs at least one member; All needs every member (and grows as the category does). All is only available when the link is Required — an optional link can never require everything.Tag Combo (Optional) — e.g. #archive-file. Both conditions must hold simultaneously: the component is in the category and carries the tag. Leave blank for a plain category assignment. If you get a warning that no current components satisfy the combo, saving is still allowed — the requirement resolves live, so future components that qualify will satisfy it.",{"id":1341,"title":1342,"titles":1343,"content":1344,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#individual-link-fields","Individual-link fields",[189],"When you're linking a specific component, extra fields appear, each valid in its own context: Version Constraint (Optional) — technology links only. Accepted formats: FormatExampleExact14.17.0Comparisons>=14.0.0, \u003C19Wildcards14.x, 1.*Tilde \u002F caret~14.2, ^14.0.0Hyphen range14.0.0 - 19.0.0OR`14 An unparseable constraint counts as unverified: penalized under lax engine mode and a no-match under strict. Endpoints (Optional) — the endpoints this requirement is expected at (\u002Fapi\u002Fv1\u002Fpath). Meaningful mainly with co-location. Co-location — a checkbox, \"Same endpoint as the required primitive.\" It only appears when the playbook declares at least one required primitive (and never on primitive or category\u002Ftag links). When set, the link only counts where its endpoints intersect the endpoints of the playbook's required primitives — a strict, both-ways check. It is the field that kills false positives where every ingredient exists but never in the same place. (Full semantics: Requirements.) Quirk Impact — Enabling or Mitigating. The same quirk can play either role in different playbooks; mitigations weigh heavier in scoring. State Polarity — Present or Absent, for stateful quirks. A requirement written as absent is satisfied only by a confirmed absence — not by silence. Yield — on gadget links, the Yields on success toggle marks the gadget as a playbook output. See Declare Yields. Boundary Refinement — \"Refine this component within its boundary.\" For individual links that sit inside an Any-mode category\u002Ftag boundary and need their own conditions (a version, extra quirks) on top of the boundary match. Yield links are never treated as boundary refinements.",{"id":1346,"title":1347,"titles":1348,"content":1349,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#scoped-children","Scoped children",[189],"Precision comes from structure, so assignments accept scoped children. On an assigned component row you'll find Add Quirks, Add Vectors, Add Gadgets, Add Categories, and Add Tags — each child with its own Required \u002F Optional and, where relevant, polarity and impact. On a vector, Add CLVQ attaches a quirk to that vector, and Nested Vectors goes one level deeper; on gadgets, Add CLGV and Add CLGQ do the same. The payoff is exact-parent matching: a quirk required inside Node.js is not satisfied by the same quirk anywhere on the asset. Structural requirements buy precision that flat links can never express.",{"id":1351,"title":1352,"titles":1353,"content":1354,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#managing-links","Managing links",[189],"Each row offers Edit details and Remove. Sections can be wiped with Clear Components — with one exception: \"Yielded links are kept. This cannot be undone.\"",{"id":1356,"title":1357,"titles":1358,"content":1359,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#if-submit-is-disabled","If submit is disabled",[189],"The rail shows the reason. The common ones: All mode requires Required (or Optional + All is not allowed) — flip the link to Required or use Any.Quirk impact required — pick Enabling or Mitigating.State polarity required \u002F Polarity required for stateful quirks — stateful quirks need Present or Absent.CLVQ targets a vector that is not linked — add the vector before the quirk that hangs off it.Vector category links cannot use Optional + All — category mode on vectors forbids optional-all.",{"id":1361,"title":1362,"titles":1363,"content":1364,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#worked-example-the-zip-slip-trigger","Worked example: the Zip Slip trigger",[189],"The Authoring Guide designs this playbook; here is the same design expressed in the UI: Link Component → Individual → Technologies → Java — Requirement: Optional. Disproportionately affected, but not part of the detection path.Link Component → Individual → Functionalities → File Upload — Requirement: Required. The broadest gate: no upload surface, no attack.On the File Upload row, Add Vectors → Category — category File type, Tag Combo #archive-file, Mode Any, Required. One assignment covers ZIP, TAR, JAR, and every archive format you tag in the future.On the File Upload row, Add Quirks → server-side extraction — Required, Impact Enabling. This is the condition that's invisible from the upload UI — the reason it's a required CLQ is that the engine will hold the playbook and keep prompting until a hunter confirms or rules it out. Confirm with Link. The trigger is now exactly three conditions plus one optional signal — lean, precise, and impossible to fire on a target without server-side extraction.",{"id":1366,"title":337,"titles":1367,"content":1368,"level":276},"\u002Fplaybooks\u002Flink-components-to-a-playbook#whats-next",[189],"Declare Yields — what this playbook produces when it succeeds.Requirements — the full mechanics reference behind every field above.",{"id":194,"title":193,"titles":1370,"content":1371,"level":270},[],"Give a playbook outputs — capabilities other playbooks can require.",{"id":1373,"title":1374,"titles":1375,"content":1376,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#what-a-yield-is","What a yield is",[193],"A yield is what the playbook produces when it succeeds — a capability that lands on the asset as a primitive. Yields are how chains form: a later playbook can require a primitive, and the suggestion only appears once this playbook has actually succeeded.",{"id":1378,"title":1379,"titles":1380,"content":1381,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#two-ways-to-declare-one","Two ways to declare one",[193],"",{"id":1383,"title":1384,"titles":1385,"content":1386,"level":444},"\u002Fplaybooks\u002Fdeclare-yields#self-contained-yield-a-new-capability","Self-contained yield (a new capability)",[193,1379],"For chain-specific capabilities with no library identity — things like Arbitrary File Overwrite or an internal foothold: Open the playbook's Yields panel.Click Create Yield.Type the name in the New yield name... field and press Create (Esc cancels). The name becomes a self-contained primitive: it lives only as a link in the chain, never as a library component. Names must be unique — creating an existing one is rejected.",{"id":1388,"title":1389,"titles":1390,"content":1391,"level":444},"\u002Fplaybooks\u002Fdeclare-yields#gadget-yield-an-existing-capability","Gadget yield (an existing capability)",[193,1379],"When the capability the playbook earns is a real concept in your library — Stored XSS, Open Redirect — don't create a parallel one: In the playbook's Components panel, find the gadget link (or link it first).Toggle Yields on success on that link. The gadget shows up in the Yields panel with a Gadget-marked badge. Either way the capability becomes a primitive on the asset — and the distinction matters in matching: requirements for a gadget can also be satisfied by a normal observation, while a self-contained primitive can only ever be earned. Rule of thumb: if it has a library page and a hunter could assign it during recon, it's a gadget yield. If nobody would ever assign it because it can only be achieved, it's self-contained.",{"id":1393,"title":1394,"titles":1395,"content":1396,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#grant-modes","Grant modes",[193],"When a playbook declares more than one yield, a Grant all yields on success toggle appears in the Yields panel: On (default) — every yield is granted automatically when the playbook is marked successful.Off — the hunter is prompted to pick which yields actually applied on that target. Real runs are messy; this keeps the record honest. Playbooks with a single yield don't need the toggle — it grants when it succeeds.",{"id":1398,"title":1399,"titles":1400,"content":1401,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#endpoint-prompt-on-earn","Endpoint prompt on earn",[193],"The gear icon on a yield opens its configuration: Prompt for endpoint when earned — when on, granting this yield asks which endpoint it was discovered on, and stores it on the earned link. This feeds the same endpoint discipline that powers co-location.",{"id":1403,"title":1404,"titles":1405,"content":1406,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#removing-a-yield","Removing a yield",[193],"A self-contained yield: Delete yield — it disappears from the playbook (and is revoked wherever it was earned, via the normal retraction cascade).A gadget yield: Remove yield (keeps gadget linked) — the gadget stays a requirement; only the yield marking is removed.",{"id":1408,"title":337,"titles":1409,"content":1410,"level":276},"\u002Fplaybooks\u002Fdeclare-yields#whats-next",[193],"Yields and Primitives — the model behind this page.Requirements — how a later playbook requires an earned primitive.",{"id":198,"title":197,"titles":1412,"content":1413,"level":270},[],"Open a suggestion, read it, execute, record — and what each outcome does.",{"id":1415,"title":1416,"titles":1417,"content":1418,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#where-suggestions-live","Where suggestions live",[197],"Open an asset → Suggestions → Playbooks. You'll see ranked suggestion cards (sortable by Score or Name), with the checklist sections above them. Click a card to open the playbook in a read-only view — the body, requirements, and yields — with a back button to return. The card's menu opens the playbook's own notespace if you need to edit it. Work the suggestions the engine actually produced. Executing unrelated playbooks burns time and poisons the outcome history with noise.",{"id":1420,"title":1421,"titles":1422,"content":1423,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#read-it-before-you-run-it","Read it before you run it",[197],"Every suggestion shows its reasoning: which requirements matched, how specific the match is, and what the playbook yields if it succeeds. If a match looks wrong, fix the underlying data before testing — editing a link, correcting a polarity, adding the endpoint that was missing.",{"id":1425,"title":1426,"titles":1427,"content":1428,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#execute","Execute",[197],"Do the work outside Nimbus Vault, within program rules. The vault is where knowledge lives, not where exploitation happens.",{"id":1430,"title":1431,"titles":1432,"content":1433,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#record-the-outcome","Record the outcome",[197],"Each suggestion card carries three actions: ActionTooltipWhat it does✓Mark playbook as successfulGrants the playbook's yields as primitives✗Mark playbook as failedRetires the suggestion — the engine stops surfacing it−Mark playbook as not applicableRetires it as irrelevant, without recording a failed test On success, yields are attached to the asset. If the playbook is set to grant all, that happens silently; if it's set to hunter-picks, you're prompted to select which earned primitives actually applied. Yields configured with \"Prompt for endpoint when earned\" also ask where the capability was discovered — record it when you can; it feeds co-location. Whichever outcome you choose, the card moves into the asset's History under Playbooks.",{"id":1435,"title":1436,"titles":1437,"content":1438,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#after-a-success","After a success",[197],"The earned capabilities appear in the asset's Primitives panel — read-only, the permanent record of what was achieved.Playbooks that require those capabilities can now appear as new suggestions. That cascade is the vault working as intended (how chains form).",{"id":1440,"title":1441,"titles":1442,"content":1443,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#retracting","Retracting",[197],"Mistakes are correctable: open the asset's History → Playbooks and retract the outcome. A retracted success revokes the yields it granted, and anything that was standing on them is re-evaluated — downstream playbooks that lose a required primitive revert with a visible notice. The history trail stays intact.",{"id":1445,"title":337,"titles":1446,"content":1447,"level":276},"\u002Fplaybooks\u002Frun-a-playbook#whats-next",[197],"Keep the loop tight: back to mapping as you discover more.See the full vocabulary in the glossary.",{"id":202,"title":201,"titles":1449,"content":1450,"level":270},[],"Build playbooks that fire at the right moment — the detection-path method.",{"id":1452,"title":1453,"titles":1454,"content":1455,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#a-hunting-tool-not-a-reference-document","A hunting tool, not a reference document",[201],"The instinctive way to build a playbook is to document a vulnerability: capture every component involved, every variant, every technique, and save it. The result looks thorough — and it never fires. A reference document is something you consult after you already suspect a vulnerability. A hunting tool fires before you have consciously made the connection, because the conditions you have mapped already satisfy its trigger. Those are different goals, and they produce different playbooks. A playbook's component requirements are not a description of a vulnerability. They are the minimum set of observable signals that tell the Nexus Engine \"this playbook is now relevant to this target.\"",{"id":1457,"title":1458,"titles":1459,"content":1460,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#the-detection-path-question","The detection path question",[201],"Before you assign a single component, answer this: What would I need to observe in a target for this attack to become worth testing? Not \"what are all the components involved\" — at what point in your reconnaissance does the playbook become relevant, and what observable signals mark that point? Most playbooks need only two or three component types to define a meaningful trigger. The rest belongs in the playbook body. Forcing every type into the requirements doesn't make a playbook more rigorous — it makes it harder to trigger, slower to assign, and noisier.",{"id":1462,"title":1463,"titles":1464,"content":1381,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#the-building-blocks","The building blocks",[201],{"id":1466,"title":1467,"titles":1468,"content":1469,"level":444},"\u002Fplaybooks\u002Fauthoring-guide#required-is-an-and-gate","Required is an AND gate",[201,1463],"Required does not mean \"this field must be filled in.\" Required means \"this component must be confirmed and assigned before this playbook is considered applicable.\" All required components together form the sufficient condition: the engine stays silent until every one is satisfied. This makes the choice of required components the most consequential decision in playbook design: Too few required conditions → the playbook fires on irrelevant targets. Noise.Too many → it can never fire in black-box hunting. Silence. The goal is the minimum set that fires at the right time and not before.",{"id":1471,"title":1472,"titles":1473,"content":1474,"level":444},"\u002Fplaybooks\u002Fauthoring-guide#optional-components-shape-confidence","Optional components shape confidence",[201,1463],"An optional component does not gate the playbook — it weights the suggestion. Present raises confidence; absent lowers it. Use it for signal that matters but cannot be a hard requirement: a Technology that is disproportionately affected, or a Gadget that varies by application. Required components define when the playbook fires; optional components define how confidently.",{"id":1476,"title":1477,"titles":1478,"content":1479,"level":444},"\u002Fplaybooks\u002Fauthoring-guide#encode-blind-spots-as-required-quirks","Encode blind spots as required quirks",[201,1463],"A required component-level quirk (CLQ) is not just a gate — it is a proactive prompt. When a playbook is partially satisfied and the only missing piece is a required CLQ, the engine turns it into a proactive prompt asking you to confirm that condition. This lets you encode the things you know you would forget. If you always map a file upload that accepts archives and move on without checking whether the server extracts them, make \"server-side extraction\" a required CLQ — and never skip it again.",{"id":1481,"title":1482,"titles":1483,"content":1484,"level":444},"\u002Fplaybooks\u002Fauthoring-guide#categories","Categories",[201,1463],"A category assignment replaces a specific component with a category-wide condition: instead of requiring Email & Password Login, require any Functionality in the Authentication category. One assignment covers every variant, including ones that don't exist yet. The type is always locked by the slot: a category on a Functionality slot resolves against functionalities only. If any member of the category makes the playbook relevant, use a category assignment; if only a subset does, use the next tool.",{"id":1486,"title":1487,"titles":1488,"content":1489,"level":444},"\u002Fplaybooks\u002Fauthoring-guide#tags-and-category-tag","Tags and category + tag",[201,1463],"Tags live on components in the library and travel with them. A category + tag assignment requires both conditions simultaneously — the component must be in the category and carry the tag. This is how you handle variance without multiplying playbooks. One playbook requiring File type + #archive-file covers ZIP, TAR, JAR, and every future format you tag — no new playbook ever needed. If you find yourself writing near-identical playbooks that differ only by which component is involved, collapse them into one and let tags do the work.",{"id":1491,"title":1492,"titles":1493,"content":1494,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#the-seven-principles","The seven principles",[201],"Adapted from the Nimbus playbook design methodology: Map the detection path, not the vulnerability. Requirements are trigger conditions. Exploitation steps, variants, and language nuance belong in the body.Use required components as sequential filters. Each one should eliminate a meaningful subset of irrelevant targets. If removing it changes nothing, it isn't load-bearing.Encode your blind spots as required CLQs. The engine will hold the playbook partially satisfied and keep asking until you confirm or rule out the condition.Let context do its share. If a competent hunter would naturally observe and record it, don't systematize it.Keep the trigger lean, push detail downstream. The body is for what to do after the playbook fires — never for what the engine needs to decide it should.Use tags to absorb variance. One playbook tagged across all affected variants beats one playbook per variant.Ask the minimum-components question last. Challenge every requirement: can I remove it and still not fire on irrelevant targets? If yes, remove it.",{"id":1496,"title":1497,"titles":1498,"content":1499,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#case-study-zip-slip","Case study: Zip Slip",[201],"Step 1 — the research. Zip Slip is directory traversal through archive extraction: it needs an upload that accepts archives, and server-side extraction of those archives. Step 2 — the detection path question. What would I need to observe for Zip Slip to become worth testing? A file upload — no upload surface, no attack. This is the broadest gate.The upload accepts archives — an image-only upload has no exposure. Handled by a tag, not by naming every format.The server extracts what was uploaded — storing archives isn't enough. This condition is invisible from the upload interface, which is exactly why it must be encoded as a required CLQ. Java is meaningful context on top — disproportionately affected — but it is not part of the detection path, so it is optional. Object Storage is the opposite kind of context: where uploads land in a bucket, local extraction is less likely, so it is an optional mitigator. Step 3 — the final playbook. Required Components:\n\n  [Functionality]\n  File Upload  (Required)\n    [CLV] File type + #archive-file — Required\n    [CLQ] server-side extraction — Required\n\n  [Technology]\n  Java — Optional (confidence signal)\n\n  [Quirk]\n  Object Storage — Optional (mitigating)\n\nExecution Steps (in the playbook body):\n  1. Craft an archive whose filenames contain traversal sequences\n  2. Upload it through the identified functionality\n  3. Observe whether traversal paths are preserved server-side\n  4. Attempt to overwrite a known file to confirm arbitrary write\n  5. Chain to RCE by targeting files the server process will execute Notice what is not there: no gadget naming the extraction library (varies by app, unconfirmable black-box), no vector naming the filename field (implicit in confirmed extraction), no quirk for missing path validation (that is what you are testing for). All of it is real, useful knowledge — none of it belongs in the trigger.",{"id":1501,"title":1502,"titles":1503,"content":1504,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#before-you-finalize","Before you finalize",[201],"Is every required component observable during normal reconnaissance, without a dedicated investigation?Does each required component eliminate a meaningful subset of irrelevant targets?Is there any required component that can almost never be confirmed black-box?Is there a condition that is both necessary and easy to forget? Is it a required CLQ?Could two playbooks be collapsed into one with better tag usage?Is there anything in the requirements that a hunter would only need after deciding to run the playbook? If those all hold, you have built a hunting tool.",{"id":1506,"title":1507,"titles":1508,"content":1509,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#the-deeper-principle","The deeper principle",[201],"Nimbus is not a vulnerability database. It is a context engine. A database stores information and retrieves it when you query; a context engine observes the context you are building and surfaces relevant attack surface automatically. For that to work, it needs to know the right conditions under which each playbook becomes relevant. Too broad — noise. Too narrow — silence. The precise middle ground is what this guide is about.",{"id":1511,"title":337,"titles":1512,"content":1513,"level":276},"\u002Fplaybooks\u002Fauthoring-guide#whats-next",[201],"Requirements — every assignment level and property in detail.Yields and Primitives — what playbooks produce, and how chains form.",{"id":206,"title":205,"titles":1515,"content":1516,"level":270},[],"Every assignment level and property a playbook requirement can carry.",{"id":1518,"title":1519,"titles":1520,"content":1521,"level":276},"\u002Fplaybooks\u002Frequirements#what-a-requirement-is","What a requirement is",[205],"A playbook requirement tells the engine what must be observed before the playbook becomes relevant. Requirements come in different levels (what they point at) and properties (how they behave when matched). This page is the full mechanics reference — for the how to think about them, read the Authoring Guide.",{"id":1523,"title":1524,"titles":1525,"content":1526,"level":276},"\u002Fplaybooks\u002Frequirements#assignment-levels","Assignment levels",[205],"A requirement can point at a single component, at a scoped child of a component, or at a category: LevelResolves againstExampleIndividual componentOne specific entry in the libraryTechnology: Node.jsComponent-Level Vector (CLV)A vector observed inside a specific parent.zip inside File UploadComponent-Level Quirk (CLQ)A quirk observed inside a specific parentserver-side extraction inside File UploadQuirk on a vector (CLVQ)A quirk attached to a component-level vectorInput Reflection on Json Request BodyNested vector (CLVV)A vector inside another vectorVector chainingComponent-Level Gadget (CLG)A gadget nested inside a parent componentinnerHTML inside HandlebarsCategoryAny component in a categoryAny Functionality in AuthenticationCategory + tagComponents in a category carrying a tagAuthentication + #login Scoped matching requires the exact parent. A vector scoped inside one functionality does not satisfy a requirement for the same vector type scoped inside a different functionality — .zip on File Upload is not .zip on Archive Creation. This is what makes scoping worth doing: it encodes where a capability lives, not just that it exists. Category mode: any or all. An \"any\" category requirement is satisfied by at least one member. An \"all\" requirement needs every member of the category — and it grows as the category does, so a new component added to a category becomes a new required condition for every playbook that requires the whole category. The type is locked by the slot. A category assignment resolves only against the component type it sits in — a category on a Technology slot never resolves against functionalities that share the label.",{"id":1528,"title":1529,"titles":1530,"content":1381,"level":276},"\u002Fplaybooks\u002Frequirements#properties","Properties",[205],{"id":1532,"title":1533,"titles":1534,"content":1535,"level":444},"\u002Fplaybooks\u002Frequirements#required-the-hard-gate","Required — the hard gate",[205,1529],"All required components together form an AND gate. The playbook is excluded entirely until every required component is satisfied — later scoring never runs. A partially satisfied playbook does not sit silently; its missing required components become proactive prompts.",{"id":1537,"title":1538,"titles":1539,"content":1540,"level":444},"\u002Fplaybooks\u002Frequirements#optional-the-confidence-signal","Optional — the confidence signal",[205,1529],"Optional components never gate. Once the required set is satisfied, the playbook fires whether or not they are present; their absence lowers confidence, their presence raises it. Optional components are how you encode meaningful-but-unconfirmable context (an affected framework, a risky ecosystem) without creating silence.",{"id":1542,"title":1543,"titles":1544,"content":1545,"level":444},"\u002Fplaybooks\u002Frequirements#enabling-and-mitigating-quirks","Enabling and mitigating quirks",[205,1529],"A quirk requirement can act as an enabler (its presence makes the outcome more likely) or a mitigator (its presence blocks or dampens the outcome). The same quirk can be an enabler in one playbook and a mitigator in another — the role is set per assignment. Mitigating factors carry more weight when absent, because a single mitigation can block an exploit while a single enabler rarely guarantees one.",{"id":1547,"title":1548,"titles":1549,"content":1550,"level":444},"\u002Fplaybooks\u002Frequirements#present-and-absent-quirk-polarity","Present and absent — quirk polarity",[205,1529],"Some quirks are stateful: what matters is whether the target currently exhibits the behavior or explicitly does not. These carry a polarity — present or absent — and the reactive checklist only offers objectives whose polarity matches what was actually observed on the asset. A required quirk written as \"does not exhibit X\" is satisfied only by a confirmed absence, not by silence.",{"id":1552,"title":1553,"titles":1554,"content":1555,"level":444},"\u002Fplaybooks\u002Frequirements#version-constraints","Version constraints",[205,1529],"Technology requirements can carry a version constraint — exact versions, comparisons (>=14, \u003C19), and ranges. How the engine treats constraints is a workspace setting: Lax — unknown versions are still included, with a confidence penalty.Strict — a technology whose version cannot be verified never satisfies a versioned requirement, and unknown versions are excluded. Lax favors coverage during black-box hunting; strict favors precision when version data is reliable.",{"id":1557,"title":1558,"titles":1559,"content":1560,"level":444},"\u002Fplaybooks\u002Frequirements#co-location","Co-location",[205,1529],"A playbook-only flag on an individual component link: \"the same endpoint as the required primitive.\" The flagged component only counts where its recorded endpoints intersect the endpoints of the playbook's required primitives — the union of all of them. It is available only when the playbook has at least one required primitive.It is strict both ways: no endpoints recorded on the component, or no endpoints on the primitives, means no match.A failed required co-located link excludes the playbook entirely; a failed optional one just lowers the score. This is how a playbook avoids the classic false positive where every ingredient exists on a target but never in the same place.",{"id":1562,"title":1563,"titles":1564,"content":1565,"level":444},"\u002Fplaybooks\u002Frequirements#primitive-requirements","Primitive requirements",[205,1529],"A requirement can demand a self-contained primitive rather than a library component — a capability granted by an earlier playbook's success. Nothing observed can satisfy it; it must be earned. (A required gadget works the other way around: it is satisfied by observation or a grant.) See Yields and Primitives.",{"id":1567,"title":1568,"titles":1569,"content":1570,"level":276},"\u002Fplaybooks\u002Frequirements#how-the-engine-treats-requirements","How the engine treats requirements",[205],"Required and missing → playbook excluded; the gap becomes a prompt on the asset.Scoped and matched at the right level → a more specific match, ranked higher than a flat one.Optional → tuned into the score.Satisfied entirely → the playbook appears in the asset's suggestions, ranked against everything else that matched.",{"id":210,"title":209,"titles":1572,"content":1573,"level":270},[],"What playbooks produce on success, and how earned capabilities form chains.",{"id":1575,"title":1576,"titles":1577,"content":1578,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#yields-what-a-playbook-produces","Yields: what a playbook produces",[209],"Requirements describe what a playbook needs. A yield declares what it produces — the potential: a capability it will grant to the asset on success. A yield can target: A library gadget — an existing reusable component like Stored XSS or Open Redirect. Because it has a library entry, a hunter can also observe and link it during recon; the yield grants that same capability on success.A self-contained primitive — a chain-only capability that exists nowhere else, like Arbitrary File Overwrite or an internal foothold. These never pollute the component library: they have no library page, and the only way they exist on an asset is a playbook granting them. Not every capability a playbook demonstrates should be a yield. Declare a yield when another playbook could one day start from it — that is the test.",{"id":1580,"title":1581,"titles":1582,"content":1583,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#primitives-the-confirmed-capability","Primitives: the confirmed capability",[209],"A yield is a potential; a primitive is that yield confirmed. When a playbook succeeds, its declared yields are granted to the asset as primitives — the same capabilities, now real on the target. The playbook's Yields panel and the asset's Primitives panel are two views of one thing. Primitives arrive in two kinds, and they differ in how they can exist on an asset: Gadget primitives — library gadgets granted by a yield. Because they have a library entry, they can also be observed and linked during recon; the granted copy joins the asset's earned capabilities.Self-contained primitives — chain-only capabilities with no library entry. They can't be reconned, linked, or inferred: a successful playbook is the only way they exist. The asset's Primitives panel is read-only — the only way in is a successful playbook, and the only way out is retracting that outcome. That immutability is a feature. A primitive means someone demonstrated something, not that someone ticked a box.",{"id":1585,"title":1586,"titles":1587,"content":1588,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#granting-yields","Granting yields",[209],"When you mark a playbook successful: Grant all — its declared yields are all attached to the asset silently.Pick — for playbooks with more than one yield, you choose which actually materialized. Real runs are messy: you got the shell but never found credentials. The vault records what happened, not what could have. If a yield's discovery happened on a specific endpoint, the vault asks for it at grant time and stores it on the earned link — the same endpoint discipline that powers co-location, now applied to capabilities you earned rather than observed.",{"id":1590,"title":1591,"titles":1592,"content":1593,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#how-capabilities-satisfy-requirements","How capabilities satisfy requirements",[209],"A playbook can require a capability a previous playbook yields — and how that requirement can be satisfied depends on what it targets: A gadget (Stored XSS) — satisfied the normal way: the gadget counts when it is mapped on the asset, whether observed during recon or granted by a yield. A chain that depends on one can fire from observation alone.A self-contained primitive (Arbitrary File Overwrite) — satisfied only by a successful playbook granting it. There is nothing to observe, and it cannot be linked manually. That is how chains form. Mapping the XSS gadget is enough to make XSS Escalation Paths eligible; Arbitrary File Overwrite Escalation Paths stays excluded until the primitive has actually been earned.",{"id":1595,"title":562,"titles":1596,"content":1597,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#meta-playbooks",[209],"Because a self-contained primitive requirement consumes the capability rather than the route to it, some playbooks are deliberately written without an upstream: an escalation playbook that takes Arbitrary File Overwrite and raises it, regardless of which playbook granted it. Write the escalation knowledge once, and every path that lands on that primitive gets it for free.",{"id":1599,"title":1600,"titles":1601,"content":1602,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#a-worked-chain","A worked chain",[209],"Archive Path Traversal (zip-slip)\n  └─ grants: Arbitrary File Write\n       └─ enables: overwrite a served file\n            └─ grants: Stored XSS\n                 └─ enables: an escalation playbook\n                      └─ grants: privileged action on the target\n                           └─ account takeover Each stage was a separate playbook with its own requirements. The stages wired through self-contained primitives could not fire until the previous one succeeded — and none of them needed to know how the previous one was achieved. The suggestion list only grows as you work through a chain, because earned primitives stay earned.",{"id":1604,"title":1605,"titles":1606,"content":1607,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#retraction-and-the-cascade","Retraction and the cascade",[209],"Marking a success is a claim; claims can be corrected. If you retract a success: The yields it granted are revoked from the asset.Every playbook whose requirement depended on a revoked primitive is re-evaluated — downstream suggestions that were standing on that primitive are reverted with it.The history keeps the full trail; nothing about the correction is hidden. This is also why outcomes are recorded honestly in the first place: the cascade only works when the data is true. See Outcomes and History.",{"id":1609,"title":337,"titles":1610,"content":1611,"level":276},"\u002Fplaybooks\u002Fyields-and-primitives#whats-next",[209],"Outcomes and History — recording runs the engine can trust.Chains — how chains are recognized as a methodology.",{"id":214,"title":213,"titles":1613,"content":1614,"level":270},[],"Recording what actually happened — the feedback loop between a run and the engine.",{"id":1616,"title":1617,"titles":1618,"content":1619,"level":276},"\u002Fplaybooks\u002Foutcomes-and-history#three-outcomes","Three outcomes",[213],"Every playbook run ends in one of three states: OutcomeMeaningEffect on the vaultSuccessThe playbook's capability was achievedGrants its yields as primitives; can satisfy playbooks that require themFailedIt was applicable, but did not work hereThe suggestion is retired — the engine stops surfacing itNot applicableIt is genuinely irrelevant to this assetRetired as noise, without recording a failed test Success earns. Failed and not-applicable prune. Both directions make the vault better: a failed run is still knowledge, and a not-applicable answer removes a suggestion that would otherwise keep asking for attention.",{"id":1621,"title":1622,"titles":1623,"content":1624,"level":276},"\u002Fplaybooks\u002Foutcomes-and-history#what-recording-a-run-does","What recording a run does",[213],"Recording an outcome moves the playbook out of the active suggestion list and into the asset's history. From then on: Success stands as evidence — and every playbook that required those capabilities can now match.Failed stays on record: you tested it, it did not apply, the engine reasons with that truth.Retracting a success revokes the yields it granted and cascades through anything that depended on them (see Yields and Primitives). Nothing is deleted. The reasoning trail — what fired, when, and what happened — lives in the playbook's and the asset's history long after you forget the details.",{"id":1626,"title":1627,"titles":1628,"content":1629,"level":276},"\u002Fplaybooks\u002Foutcomes-and-history#history-per-asset","History per asset",[213],"Each asset keeps a history with three sections: Playbooks — every run outcome, with its yield trail.Proactive Checklist — prompts you resolved by hand rather than by assignment.Reactive Checklist — component objectives you checked or dismissed. Items stay in history permanently unless you remove them. Removing an entry makes it eligible again — a prompt can ask once more, a dismissed objective can resurface. That is the escape hatch for mistakes, not the default: the record is meant to be trustworthy, so corrections are deliberate. The history is the engine's memory of your evidence. Recording an outcome you did not actually test — a success to unlock a chain, a failed run to quiet a suggestion — corrupts every suggestion that follows. Regressions are worse than omissions here.",{"id":1631,"title":1632,"titles":1633,"content":1634,"level":276},"\u002Fplaybooks\u002Foutcomes-and-history#the-discipline","The discipline",[213],"Record outcomes only for playbooks you actually ran.Record them with the yield endpoint when you have it.Prefer \"not applicable\" for noise and \"failed\" for tested-and-didn't-work; the difference matters in the trail.Correct mistakes by retracting — never by leaving a false success in place.",{"id":1636,"title":337,"titles":1637,"content":1638,"level":276},"\u002Fplaybooks\u002Foutcomes-and-history#whats-next",[213],"The loop closes here and reopens at the top: map what you learned, and the engine reasons from better data.",{"id":179,"title":10,"titles":1640,"content":1641,"level":270},[],"Requirements in, capabilities out — the recipes of your threat library.",{"id":1643,"title":1644,"titles":1645,"content":1646,"level":276},"\u002Fplaybooks#a-playbook-is-a-recipe","A playbook is a recipe",[10],"A playbook describes how a situation is exploited: if a target has these things, this capability becomes available. Two halves: Requirements — the components that must be observed for the playbook to apply. These are hard gates: miss one and the playbook is excluded.Yields — the capabilities the playbook grants when it succeeds — earned primitives that feed back into matching. Requirements can be loose or strict: a plain component, a component scoped inside another, a category match, or a co-located requirement. Strictness changes how specific a match is, which changes its rank, but never bypasses a gate.",{"id":1648,"title":1273,"titles":1649,"content":1650,"level":276},"\u002Fplaybooks#in-this-section",[10],"Create a Playbook — the Add Playbook drawer, the body, and the notespace.Link Components to a Playbook — build the trigger: modes, required\u002Foptional, scoping, every field.Declare Yields — give the playbook outputs other playbooks can require.Authoring Guide — the detection-path method for building playbooks that fire at the right moment.Requirements — every assignment level and property a requirement can carry.Yields and Primitives — what playbooks produce, and how chains form.Outcomes and History — recording runs honestly, and what each outcome does.",{"id":1652,"title":337,"titles":1653,"content":1654,"level":276},"\u002Fplaybooks#whats-next",[10],"See the machinery that decides which playbook applies: the Nexus Engine.",{"id":225,"title":224,"titles":1656,"content":1657,"level":270},[],"Give an AI agent scoped access to your workspace over MCP.",{"id":1659,"title":1660,"titles":1661,"content":1662,"level":276},"\u002Ftools\u002Fmcp-server#what-a-connection-does","What a connection does",[224],"A connection lets an AI agent work in your workspace on your behalf, with your access level — over the Model Context Protocol (MCP). The agent can read what you can read and do what you can do, scoped to that workspace and bounded by the capabilities you leave enabled on the connection. Everything below happens in Workspace Settings → Integrations. Every member can see the workspace's connections (name, owner, status, expiry) — transparency without secrets. Owners manage their own; admins can revoke any. Agent connections are a Pro feature. Each member can hold up to 10 connections per workspace.",{"id":1664,"title":1665,"titles":1666,"content":1667,"level":276},"\u002Ftools\u002Fmcp-server#creating-a-connection","Creating a connection",[224],"Open the Integrations tab and create one. Give it a name you will recognize later — Claude Code — laptop beats test — and choose an expiry: 90 days by default, or 30 \u002F 90 \u002F 365 \u002F never.\n  The connection token (nv_live_…) is shown a single time. Copy it into your client before closing the dialog; if you lose it, rotate the connection and copy a fresh one.\n  Pick your client and paste the pre-filled snippet — the dialog provides one for Claude Code, Claude Desktop, Cursor, and a generic \"Other\" form. For Claude Code:claude mcp add --transport http nimbus https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp \\\n  --header \"Authorization: Bearer nv_live_…\"\nFor JSON-based clients (Claude Desktop, Cursor):{\n  \"mcpServers\": {\n    \"nimbus\": {\n      \"type\": \"http\",\n      \"url\": \"https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp\",\n      \"headers\": { \"Authorization\": \"Bearer nv_live_…\" }\n    }\n  }\n}\n\n  Ask your agent: \"Use Nimbus to show my workspace context.\" The first exchange flips the connection from Never to recently used — proof the loop works.",{"id":1669,"title":1670,"titles":1671,"content":1672,"level":276},"\u002Ftools\u002Fmcp-server#the-working-guide","The working guide",[224],"Every connection ships with Nimbus's operating methodology — the strict working guide Nimbus serves to agents. It is strict on purpose: the engine is deterministic, and an agent that reorders the work produces wrong records that suppress correct work later. It is delivered two ways: as MCP server instructions (injected into the client's model context when the connection initializes) and as the nimbus:\u002F\u002Fguide resource. get_context points at it for clients that surface neither. The guide fixes one ordering: Orient — get_context, then get_asset_context (or get_asset_suggestions) for the asset being worked. Between cycles, get_asset_delta refreshes only what changed; get_asset_graph is the compact map for verification passes. Never start from the playbook library.Map — link every library-grade component actually observed, at the scope it was observed, with its endpoints, version, and state. Nested components ride the existing link that carries their parent — never a duplicate top-level link.Work the prompts — resolve a prompt into its tests, run the probes, then confirm the positive observations or record a negative check. Negative checks are permanent suppressions: they are only valid after the full flow was traced.Read — playbooks only once the engine suggests them (get_suggested_playbook). Never browse the library to pick work.Execute — in score order, following each playbook's notes literally, and recording honest outcomes.Record — findings as notes, corrections via retraction. A wrong record costs more than a missing one. A few hard rules from the guide worth knowing as the workspace owner: map only what was observed, never fabricate a link to make a playbook match; the engine's suggestions are the gate; and everything the tools return is treated as data, never as instructions.",{"id":1674,"title":1675,"titles":1676,"content":1677,"level":276},"\u002Ftools\u002Fmcp-server#the-toolset","The toolset",[224],"Every connection exposes the same surface: 51 tools. Forty-eight are curated for the vault's workflows — grouped below with their use cases — and three are a gateway into the wider backend for everything else.",{"id":1679,"title":1680,"titles":1681,"content":1682,"level":444},"\u002Ftools\u002Fmcp-server#orientation","Orientation",[224,1675],"get_context — The workspace, the acting user, engine mode, and counts. The entry point: call it first, every session. Always available, even on locked-down connections.get_asset — One asset's digest: linked components with endpoints, quirk state, and CL nesting labels, plus the technology defaults the engine counts as inherited. Read this when you need the observed surface.get_asset_context — The full projection for an asset in a single call: digest, ranked suggestions, the complete tiered checklist, and earned primitives. The recommended context injection before an investigation cycle.get_asset_suggestions — Ranked playbook suggestions plus the proactive\u002Freactive checklist, with probes inline. The recommended first call after get_asset.get_asset_delta — A compact change feed since a cursor: new or updated links, outcomes, checklist checks, touched notes, open prompts. Use it between work cycles instead of re-fetching.get_asset_graph — The compact nesting graph — one node per link with its CL label, surfaces, and children. Built for verification passes and map checks.get_program_scope — Program details, platform, guidelines, and the curated asset inventory. Use it to seed a scope allowlist; the assets are the authoritative inventory, the guidelines text is advisory.list_programs \u002F list_assets — The workspace's programs and a program's assets, wildcards and children included.",{"id":1684,"title":1685,"titles":1686,"content":1687,"level":444},"\u002Ftools\u002Fmcp-server#mapping-and-capture","Mapping and capture",[224,1675],"link_component_to_asset — Confirm a single observed component, with endpoints, version, and state. Endpoints are observation surfaces: the page route or concrete URL where it was seen, never the API route the feature calls. Nested children ride the parent's instances.link_components_to_asset — The recon-dump batch: up to 25 components in one transactional call. Existing links are updated in place, never duplicated — retrying after a transport error is safe.create_asset — Add an asset to a program; Wildcard types act as containers with concrete children beneath them.update_asset — Patch an asset's name, type, URL, priority, tags, or description.import_assets — Batch-create up to 500 assets from a scope list. Duplicates are reported, never overwritten.reconcile_technology_defaults — Materialize the inherited technology defaults onto an asset's technology links — the same reconciliation the web UI runs after link changes.",{"id":1689,"title":1690,"titles":1691,"content":1692,"level":444},"\u002Ftools\u002Fmcp-server#prompts-and-checklists","Prompts and checklists",[224,1675],"get_asset_checklist — The full proactive and reactive checklist. Concrete prompts carry their probes inline; category\u002Ftag prompts carry a resolution block.get_checklist_summary — A planning rollup: prompt count per playbook with matched\u002Fmissing\u002Ftotal requirement counts, plus objective counts. Use it to plan a sweep.resolve_checklist_prompt — Turn one prompt into actionable tests in a single call, plus the exact confirmation recipe.explain_prompt — Why a prompt exists: the playbook(s), the target component, expected vs recorded polarity, and what closes it.confirm_checklist_prompt — Clear a prompt by linking the observed component at the correct scope — on the existing link that already carries the parent. Returns a structured reason when nothing was linked.confirm_checklist_prompts — The bulk sweep: up to 10 confirmations per call, each with its own result.check_prompt — Record a negative result: the probe ran and found nothing, so the prompt stops resurfacing permanently. Only valid after tracing the full flow for component-level children.check_prompts — Batch up to 50 negative checks.check_objective — Mark a reactive objective complete, so it stops resurfacing and lands in the asset's history.get_probes — The test recipes for concrete component targets, or for the candidates resolved from a category\u002Ftag group.",{"id":1694,"title":1695,"titles":1696,"content":1697,"level":444},"\u002Ftools\u002Fmcp-server#suggestions-and-playbooks","Suggestions and playbooks",[224,1675],"get_asset_playbook_suggestions — The ranked list with score, confidence, and matched components.explain_suggestion — Why a playbook is or is not suggested: score breakdown when it is; the exact blocking prompts when it is not. Works even when direct read is disabled.get_suggested_playbook — The suggestion-gated read: requirements with resolved names, the note bodies (the methodology), and the yield configuration. Only allowed for playbooks currently suggested for the asset, or present in its outcome history.get_playbook \u002F list_playbooks — The raw library reads, gated by the Read playbooks directly capability. Turn that capability off to force the suggestion-driven path.find_assets_for_playbook — The reverse ranking: which assets a playbook fits, scored by the same engine.record_outcome — Record success, failed, or not applicable on a suggested playbook. Success grants the declared yields; prompted yields take their discovery endpoint. The playbook must currently be suggested.retract_outcome — Revert a recorded outcome: granted yields are revoked and dependent successes cascade-revert, all reported.get_asset_history — The asset's outcomes and checklist history.",{"id":1699,"title":1700,"titles":1701,"content":1702,"level":444},"\u002Ftools\u002Fmcp-server#library","Library",[224,1675],"get_component_catalog — The whole library in one call — ids, names, categories, tags. Use it to constrain extraction to entries that actually exist before analysing or bulk-linking.list_components — One component type, optionally filtered by text.list_component_group — Resolve a category, category+tag combo, or tag into its concrete members — the step between tier-2 prompts and get_probes.get_component — A component with its notespace: linked assets and playbooks, objectives, and probes.create_component — Create a library entry. Technologies auto-fill from the presets catalog; a same-name entry is returned as-is instead of duplicated, so agents link the existing one.search_technology_presets — Search the canonical technology catalog (the same fork the web library uses) and create with the preset's exact name, category, description, and logo.get_technology_defaults — The quirks, vectors, and gadgets a technology declares, split into what the engine assumes automatically and what waits for per-asset adoption.",{"id":1704,"title":1705,"titles":1706,"content":1707,"level":444},"\u002Ftools\u002Fmcp-server#search-and-coverage","Search and coverage",[224,1675],"search — One query across assets, components, playbooks, and notes.find_assets_by_component — Every asset that links a given component, exact links only, with endpoints and quirk state.get_coverage — Coverage and blind spots: observed components no playbook references, or the workspace's per-asset coverage, worst first.audit_links — The link-graph integrity audit: dangling targets, broken nested references, orphaned notespaces, endpointless synthetic instances. Run it after deletions.",{"id":1709,"title":1710,"titles":1711,"content":1712,"level":444},"\u002Ftools\u002Fmcp-server#notes","Notes",[224,1675],"add_note — Add a markdown note to an asset, component, technology, or playbook notespace — findings, observations, follow-ups.list_asset_notes — Keyword-search an asset's notes by title and preview before writing a duplicate.read_note — The full body of a note by id. Playbook-note reads are gated by Read playbooks directly; when it is off, get_suggested_playbook already returns note bodies.",{"id":1714,"title":1715,"titles":1716,"content":1717,"level":444},"\u002Ftools\u002Fmcp-server#the-gateway","The gateway",[224,1675],"list_functions — The backend functions this connection may call, with scope and destructiveness. Always filtered by the connection's capabilities.get_function_spec — One function's argument JSON Schema, kind, and destructiveness — check before calling.call_function — Call any allowed backend function directly: workspace ids are injected, entity ids are fenced to the workspace, and the same capability policy applies. This is how an agent reaches operations beyond the curated 48 — including destructive ones, which should be confirmed before calling.",{"id":1719,"title":1720,"titles":1721,"content":1722,"level":276},"\u002Ftools\u002Fmcp-server#capabilities-what-the-agent-may-do","Capabilities: what the agent may do",[224],"Tools are grouped into 20 capabilities — the human-facing permission units you toggle per connection. Every capability maps to explicit backend functions, and the gateway enforces it on every call, including calls made through call_function. GroupCapabilitiesObserveRead workspace dataRecon & captureCreate and update assets · Manage programs and platforms · Link components to assetsNexus loopRead playbooks directly · Record outcomes and checklist progressKnowledge authoringCreate library components · Update library components · Write notes · Author checklist objectives and probes · Author playbooksDestructiveDelete assets · Delete library components · Delete notes · Delete objectives and probes · Delete playbooks and yields · Retract recorded outcomes · Delete programs and platformsAdministrationWorkspace administration (destructive) · Read audit logs Everything is enabled by default — the policy is a deny-list. Uncheck a capability and every function mapped to it is blocked; disabled capabilities also hide their tools, so the agent never plans around something it cannot call. Two deliberate exceptions: get_context is always available (baseline orientation; its reads degrade gracefully rather than failing), and read_note stays available with its playbook-note path gated per call. Policies worth considering when you narrow a connection: Turn Read playbooks directly off to keep the agent on the suggestion-gated path — it still reads every playbook the engine surfaces for an asset.Keep the Destructive groups off unless the agent is doing deliberate housekeeping; deletions cascade and are not reversible.Workspace administration covers membership, invites, sharing, cloning, and deletion — rarely something an agent should hold.",{"id":1724,"title":1725,"titles":1726,"content":1727,"level":276},"\u002Ftools\u002Fmcp-server#managing-connections","Managing connections",[224],"Status chips — Active, Expired, or Revoked, at a glance.Rename \u002F renew \u002F rotate — lifecycle actions for the owner. Rotate immediately if a token leaks.Revoke — owners revoke their own; admins can revoke any. Revocation takes effect at the next exchange, and live sessions end shortly after.Delete — removes revoked or expired rows permanently.Leaving or being removed from a workspace deletes your connections for it.",{"id":1729,"title":1730,"titles":1731,"content":1732,"level":276},"\u002Ftools\u002Fmcp-server#security-model","Security model",[224],"Workspace-scoped. A token reaches one workspace and nothing else.No secret at rest. The raw token is never stored or logged — only a hash, used to mint short-lived sessions.Expiry by default. Connections come with an end date unless you deliberately choose otherwise.Audited. Connecting, revoking, and every write the agent makes are recorded in the workspace's audit log.",{"id":1734,"title":337,"titles":1735,"content":1736,"level":276},"\u002Ftools\u002Fmcp-server#whats-next",[224],"Share and Collaborate — the human side of working together.Search the Workspace — the same surface, driven by you.",{"id":229,"title":228,"titles":1738,"content":1739,"level":270},[],"Work the Nimbus loop from a side panel while you browse your target.",{"id":1741,"title":1742,"titles":1743,"content":1744,"level":276},"\u002Ftools\u002Fbrowser-extension#what-the-extension-is","What the extension is",[228],"The browser extension puts the vault next to the target. Instead of switching between your notes and the application you're testing, a side panel lets you map components, read suggestions, and record outcomes without leaving the page. It is built for Chrome (Manifest V3) and connects to the same workspace as the web app — same account, same permissions. The extension is in a limited rollout: it is not listed publicly yet and is distributed to users directly. If you'd like access, ask in the workspace or reach out to the team.",{"id":1746,"title":1747,"titles":1748,"content":1749,"level":276},"\u002Ftools\u002Fbrowser-extension#what-you-can-do-from-the-panel","What you can do from the panel",[228],"See the proactive checklist for the asset you're working, and resolve prompts in place — ticking a component links it to the asset immediately.Read ranked suggestions for the current target, including chain-tagged playbooks, and open them inline to review requirements and the body.Record outcomes — mark playbooks successful, failed, or not applicable, and grant earned primitives when yields come with a choice.Watch the vault update — a link you add from the panel sharpens suggestions on the web app the moment you switch back.",{"id":1751,"title":1752,"titles":1753,"content":1754,"level":276},"\u002Ftools\u002Fbrowser-extension#how-it-fits-the-loop","How it fits the loop",[228],"The extension does not replace the web app — it removes the context switch from the mapping stage. Longer sessions, authoring, and workspace administration stay in the web app; the panel is for the moment you're staring at the target and want to record what you see.",{"id":1756,"title":337,"titles":1757,"content":1758,"level":276},"\u002Ftools\u002Fbrowser-extension#whats-next",[228],"Map an Asset — the mapping flow the panel accelerates.MCP Server — the other way Nimbus meets you outside the app.",{"id":233,"title":232,"titles":1760,"content":1761,"level":270},[],"The intentionally vulnerable practice target — and how to run the full loop against it safely.",{"id":1763,"title":1764,"titles":1765,"content":1766,"level":276},"\u002Ftools\u002Ftodoer#what-todoer-is","What Todoer is",[232],"Todoer is an intentionally vulnerable full-stack task management app — the official practice environment for Nimbus Vault. It is not a CTF: no flags, no labelled vulnerability boxes. It looks and behaves like a real app because it is one, with real bugs buried in it. Difficulty: intermediate → expert. It exists so you have somewhere safe and legal to test playbooks before pointing them at a live program. A hosted instance runs at todoer.site; the source, self-hosting instructions, and disclosure policy live in the Todoer repository.",{"id":1768,"title":1769,"titles":1770,"content":1771,"level":276},"\u002Ftools\u002Ftodoer#two-ways-to-use-it","Two ways to use it",[232],"The seeded practice target. Every workspace seeded from the Starter Library includes the Todoer platform, a Todoer Bounty program, and an intentionally unmapped todoer.site asset. It is the fastest way to try the loop end to end: you supply the mapping, the engine supplies the rest.Self-host your own instance. Clone the repository and run it on a VPS with your own domain — the README covers the nginx-proxy and automatic HTTPS setup. Useful when you want a private target to rehearse against before a live rotation.",{"id":1773,"title":1774,"titles":1775,"content":1776,"level":276},"\u002Ftools\u002Ftodoer#practice-the-loop","Practice the loop",[232],"Run the full cycle against a real application: Map — open the seeded asset and link what you observe: the stack, the features, the behaviors.Match — watch ranked suggestions appear as the engine correlates your library with what you mapped.Confirm — work the checklists to turn gaps into concrete next questions.Execute — run the surfaced playbooks against the target, within its rules.Earn — record outcomes honestly; successes yield primitives that unlock the next playbook in a chain.",{"id":1778,"title":1779,"titles":1780,"content":1781,"level":276},"\u002Ftools\u002Ftodoer#ground-rules","Ground rules",[232],"Only test instances you own or are explicitly authorized to test. Todoer exists so that practice is unambiguous — self-host it, or use the hosted instance under its VDP. Real targets are governed by program scope and rules.",{"id":218,"title":10,"titles":1783,"content":1784,"level":270},[],"Capabilities that extend the workspace beyond the web app.",{"id":1786,"title":1787,"titles":1788,"content":1789,"level":276},"\u002Ftools#beyond-the-app","Beyond the app",[10],"A workspace is more useful when your tools can meet it halfway. These are the companion tools and environments that extend Nimbus Vault from outside the web app. MCP Server — give an AI agent scoped access to your workspace over MCP, with capability toggles, expiry, and revocation under your control.Browser Extension — work the Nimbus loop from a side panel while you browse your target.Todoer — the intentionally vulnerable practice target; run the full loop against it safely before you test live programs. The section grows as more companion tools ship.",{"id":244,"title":243,"titles":1791,"content":1792,"level":270},[],"Every Nimbus Vault term in one place.",{"id":1794,"title":1795,"titles":1796,"content":1797,"level":276},"\u002Freference\u002Fglossary#targets","Targets",[243],"Platform — a source of work: a bug bounty platform, a VDP, or a private engagement. Program — an organization's published scope: rules, rewards, and boundary for testing. Asset — one concrete thing you are testing: a host, an API, an app, a checkout. Assets can have children. Wildcard — a container asset type: a pattern like *.example.com that groups concrete assets beneath it; not a tracked target itself.",{"id":1799,"title":1700,"titles":1800,"content":1801,"level":276},"\u002Freference\u002Fglossary#library",[243],"Component — a reusable building block observed on targets. Five types: technology, functionality, gadget, vector, quirk. Technology — what a target is built on or running. Functionality — what a target does for its users. Gadget — an additional capability that rides along with the target. Vector — the specific way in: an attack-relevant mechanism. Quirk — behavior that could tip an attack outcome. Category — a themed grouping of components used by the engine's structured matching. Tag — a lightweight label for slicing the library and attaching conditions in playbooks. Asset-Level Component (ALC) — a component linked directly to the asset, rather than scoped inside another component. Component-Level Vector (CLV) — a vector scoped inside a specific parent component. Component-Level Quirk (CLQ) — a quirk scoped inside a specific parent component. Component-Level Gadget (CLG) — a gadget scoped inside a specific parent component. Starter Library — the curated set of components and playbooks you can seed a workspace with.",{"id":1803,"title":1804,"titles":1805,"content":1806,"level":276},"\u002Freference\u002Fglossary#engine","Engine",[243],"Nexus Engine — the deterministic, rule-based engine that matches playbooks against assets, ranks suggestions, and builds the proactive checklist. Requirement — a component a playbook needs before it can apply. Requirements are hard gates. Co-location — a requirement that two capabilities must meet at the same endpoint before they count as combined. Suggestion — a ranked playbook match, with the reasoning that produced it. Prompt — a question from the checklist: does a capability apply to this asset? Resolving it feeds the engine. Coverage — how much of what could apply to an asset you have actually confirmed. Yield — the potential a playbook declares: a capability it grants on success. Once granted, the same capability is a primitive on the asset. Primitive — the confirmed existence of a yield: a capability granted to an asset by a successful playbook, shown read-only in its Primitives panel. Gadget primitive — a library gadget granted by a yield; like any gadget, it can also be observed and linked during recon. Self-contained primitive — a yield with no library entry — a chain-only capability that can only be earned, never observed or linked. Chain — a sequence of playbooks where each success earns a capability the next one requires. Meta-playbook — a playbook that consumes a primitive regardless of how it was earned. Engine mode — the workspace setting for version matching: Lax includes unverified versions with a confidence penalty; Strict excludes them. Outcome — the recorded result of a run: success, failed, or not applicable. CAVET — Component Analysis & Vulnerability Enumeration Technique: the methodology Nimbus Vault implements — analyze targets into components, then enumerate exploitable behavior systematically.",{"id":1808,"title":1809,"titles":1810,"content":1811,"level":276},"\u002Freference\u002Fglossary#work","Work",[243],"Workspace — the container for all assets, components, playbooks, and notespaces; shared with your team. Notespace — the single page where an entity's links, notes, and history live. Endpoint — the concrete URL or path where a capability was observed. Instance — one occurrence of a component on an asset, per endpoint; instances are what co-location reasons about. Probe — a reusable note on a component describing how to check for it; surfaced alongside checklist prompts. Scope — where a link applies: directly on the asset, or inside a parent component. Agent connection — a capability-scoped token that lets an AI agent read from and write to your workspace over the Model Context Protocol (MCP).",{"id":248,"title":247,"titles":1813,"content":1814,"level":270},[],"Use the command center to find anything in the vault — and to hunt horizontally.",{"id":1816,"title":1817,"titles":1818,"content":1819,"level":276},"\u002Freference\u002Fsearch-the-workspace#one-search-across-everything","One search across everything",[247],"The command center opens with Cmd K (Ctrl K on Windows\u002FLinux). It searches the entire workspace at once — platforms, programs, assets, every component type, and playbooks — and every result opens directly. Type plain text to search names, or add filters to slice the vault. Filters combine with AND: type:playbook difficulty:high means high-difficulty playbooks only. Negation works on tags and presence: !tag:wip, !has:quirk.",{"id":1821,"title":1822,"titles":1823,"content":1824,"level":276},"\u002Freference\u002Fsearch-the-workspace#finding-the-thing-in-front-of-you","Finding the thing in front of you",[247],"has:functionality:\"File Upload\" — every entity connected to file uploads.type:asset priority:critical — the assets that matter most.version:>=14 — technology links at or above a version.created:7d \u002F updated:30d — what changed recently. Autocomplete (press Tab) completes filter names and values, and active filters appear as chips you can clear individually. The complete grammar lives in the search syntax reference.",{"id":1826,"title":1827,"titles":1828,"content":1829,"level":276},"\u002Freference\u002Fsearch-the-workspace#hunting-horizontally","Hunting horizontally",[247],"The command center is also the fastest way to answer cross-workspace questions — the ones a single asset page can never answer: \"Where is this technology?\" — has:technology:Express across every program at once.\"What did we tag as needing review?\" — !tag:reviewed or a status filter, depending on what you track.\"What does the library connect to?\" — has:gadget:\"PostMessage Listener\" to see every asset and playbook that touches it. This is the moment the vault pays you back: knowledge that was entered engagement by engagement becomes queryable across all of them.",{"id":1831,"title":1832,"titles":1833,"content":1834,"level":276},"\u002Freference\u002Fsearch-the-workspace#practical-habits","Practical habits",[247],"Filter, then read. Text alone floods; one or two filters turn the vault into an answer.Quote multi-word values — has:func:\"File Upload\".Use the chips to iterate. Build a query in the box, then refine by clearing the one filter that is too narrow.Everything is a result. If it exists in the vault — an asset, a component, a playbook, a platform — search returns it.",{"id":1836,"title":337,"titles":1837,"content":1838,"level":276},"\u002Freference\u002Fsearch-the-workspace#whats-next",[247],"Search syntax reference — every filter, alias, and operator.Map an asset — keep the vault worth searching.",{"id":252,"title":251,"titles":1840,"content":1841,"level":270},[],"Every filter in the command center, with examples. The command center (Cmd K) searches the whole workspace. Plain text matches names; filters slice by field. Filters combine with AND — every condition must hold.",{"id":1843,"title":1844,"titles":1845,"content":1846,"level":276},"\u002Freference\u002Fsearch-syntax#entity-types","Entity types",[251],"FilterValuesAliasestype:platform, program, asset, technology, functionality, gadget, vector, quirk, playbookplat, prog, tech, func \u002F fn, vuln for quirks type:* matches any entity type.type:playbook difficulty:high — high-difficulty playbooks.type:asset priority:critical — your most important assets.",{"id":1848,"title":1849,"titles":1850,"content":1851,"level":276},"\u002Freference\u002Fsearch-syntax#presence","Presence",[251],"FilterMeaningExamplehas:Has a specific linked componenthas:functionality:\"File Upload\"!has:Does not have it!has:quirktag:Carries a tagtag:oauth!tag:Does not carry it!tag:reviewed has: combines a type and a value: has:technology:Node.js, has:quirk:\"Unsafe Prototype-Chain Lookup\". Quote multi-word values. Negation is supported for has: and tag: only.",{"id":1853,"title":1529,"titles":1854,"content":1855,"level":276},"\u002Freference\u002Fsearch-syntax#properties",[251],"FilterApplies toExampleasset-type:Assetsasset-type:apipriority:Assetspriority:highseverity:Playbooksseverity:criticaldifficulty:Playbooksdifficulty:high or difficulty:7program-type:Programsprogram-type:vdpstatus:Programsstatus:activecategory:Componentscategory:authenticationvendor:Technology linksvendor:ApacheisStateful:QuirksisStateful:true",{"id":1857,"title":1858,"titles":1859,"content":1860,"level":276},"\u002Freference\u002Fsearch-syntax#version","Version",[251],"version: filters technology links by the version you recorded (not the latest available): version:14.17.0 — exactversion:>=14 \u002F version:\u003C19 — comparisonsversion:14.x — series",{"id":1862,"title":1863,"titles":1864,"content":1865,"level":276},"\u002Freference\u002Fsearch-syntax#link-modes","Link modes",[251],"Find components by how they are observed: FilterMeaning@clqComponent-level quirks (scoped quirks)@clvComponent-level vectors (scoped vectors)@clvvNested vectors@clvqQuirks on scoped vectors",{"id":1867,"title":1868,"titles":1869,"content":1870,"level":276},"\u002Freference\u002Fsearch-syntax#time","Time",[251],"FilterMeaningcreated:meCreated by youcreated:user:\u003Cname>Created by a teammatecreated:7dCreated in the last N days\u002Fweeks\u002Fmonths (d, w, m)updated:30dUpdated in the last N days\u002Fweeks\u002Fmonths",{"id":1872,"title":1873,"titles":1874,"content":1875,"level":276},"\u002Freference\u002Fsearch-syntax#interaction","Interaction",[251],"Two-character minimum for free-text search.Enter opens the top result; arrows move the selection.Tab accepts an autocomplete suggestion; filter names and values complete as you type.Active filters appear as chips — clear them individually to widen a query.Esc closes the command center.",{"id":1877,"title":1878,"titles":1879,"content":1880,"level":276},"\u002Freference\u002Fsearch-syntax#examples","Examples",[251],"type:playbook severity:critical tag:rce\nhas:functionality:\"File Upload\" version:>=14\nasset-type:web priority:critical !tag:reviewed\ncreated:user:alex updated:7d\ntype:quirk isStateful:true @clq",{"id":256,"title":255,"titles":1882,"content":1883,"level":270},[],"What lives in account settings vs. workspace settings.",{"id":1885,"title":1886,"titles":1887,"content":1888,"level":276},"\u002Freference\u002Fsettings#account-settings","Account settings",[255],"Open from your avatar. Personal to you, across every workspace: TabWhat it coversProfileYour identity — display name, photo, and account detailsPreferencesYour personal preferences for the appInvitesWorkspace invitations waiting on you — accept or declineDelete AccountAccount deletion (email-code confirmed)",{"id":1890,"title":1891,"titles":1892,"content":1893,"level":276},"\u002Freference\u002Fsettings#workspace-settings","Workspace settings",[255],"Open from the workspace menu. Shared by every member: TabWhat it coversGeneralWorkspace name, description, and identityMembersMembership and roles — invite, remove, change roles, transfer ownershipInvitationsEmail invitations and the invite link; pending invites can be resent or revokedNexus EngineThe engine mode: Lax or Strict version matchingDashboardCoverage thresholds used by Attack CoverageIntegrationsMCP server Danger actions — leaving the workspace, transferring ownership, and deleting the workspace — live at the bottom, behind confirmation. Deleting a workspace is not a per-member action to take casually. Prefer cloning or exporting when you only need a fresh start.",{"id":1895,"title":1896,"titles":1897,"content":1898,"level":276},"\u002Freference\u002Fsettings#plan-limits","Plan limits",[255],"FreeProOwned workspaces15Agent connections (per member, per workspace)—10 (expiry required by default) Membership in other people's workspaces is not limited — the cap applies to workspaces you own.",{"id":260,"title":259,"titles":1900,"content":1901,"level":270},[],"What each number on the dashboard means — and what to do about it.",{"id":1903,"title":1904,"titles":1905,"content":1906,"level":276},"\u002Freference\u002Fdashboard-metrics#attack-coverage","Attack Coverage",[259],"Which mapped components have playbook attack coverage. Every component in your library is classified by how many playbooks cover it: Mature — well covered; if this component appears on an asset, the engine has plenty to say.Developing — partially covered; a thin spot worth growing.Gap — zero playbook coverage; the library knows the component but not what to do with it. The Mature and Developing thresholds are adjustable in Workspace Settings → Dashboard — tune them to how you want the library judged.",{"id":1908,"title":1909,"titles":1910,"content":1911,"level":276},"\u002Freference\u002Fdashboard-metrics#blind-spots","Blind Spots",[259],"Mapped asset components that still have zero playbook coverage. Attack Coverage looks at the library; Blind Spots looks at your live assets: components you have already observed on real targets that no playbook can act on yet. Hover an asset to inspect which components are uncovered. A blind spot is the most actionable metric on the page: you already did the recon, the context exists, and the only missing piece is a playbook.",{"id":1913,"title":1914,"titles":1915,"content":1916,"level":276},"\u002Freference\u002Fdashboard-metrics#playbook-coverage-rate","Playbook Coverage Rate",[259],"The percentage of suggested playbooks that have been attempted — marked with success, failure, or not-applicable. Per asset, with navigation between assets. A low rate means suggestions are piling up unexamined: surface area you have mapped but not tested. It is not a score to maximize — testing everything is not the goal — but a low rate with high-priority assets is a signal.",{"id":1918,"title":1919,"titles":1920,"content":1921,"level":276},"\u002Freference\u002Fdashboard-metrics#knowledge-velocity","Knowledge Velocity",[259],"How quickly the workspace is gaining new knowledge — notes, links, checklist objectives, and notespaces created over the last 30 days. Useful as a personal rhythm check: mapping compounds, and this measures how often you are adding to the pile.",{"id":1923,"title":1924,"titles":1925,"content":1926,"level":276},"\u002Freference\u002Fdashboard-metrics#popular-components","Popular Components",[259],"The top five most-used components per type, ranked by how many assets they are mapped to. It is a quick read on what your engagements actually consist of — and a hint about which components most deserve great playbook coverage.",{"id":264,"title":263,"titles":1928,"content":1929,"level":270},[],"Quick answers to the questions that come up most.",{"id":1931,"title":1932,"titles":1933,"content":1934,"level":444},"\u002Freference\u002Ffaq#why-doesnt-a-playbook-i-know-applies-show-up-as-a-suggestion","Why doesn't a playbook I know applies show up as a suggestion?",[263],"Suggestions only exist when every required component is satisfied. The usual causes, in order: A missing required component — check the asset's checklist; partially satisfied playbooks appear there as prompts.A scoped requirement on the wrong parent — a scoped quirk or vector must be linked inside the exact parent the playbook requires (Scopes and Levels).Strict version matching — with engine mode set to Strict, technologies whose version is unverified never satisfy a versioned requirement (Requirements).Co-location without endpoints — if a requirement demands the same endpoint as a primitive, missing endpoint data means no match.",{"id":1936,"title":1937,"titles":1938,"content":1939,"level":444},"\u002Freference\u002Ffaq#why-did-a-suggestion-disappear","Why did a suggestion disappear?",[263],"Either you recorded an outcome for it — success, failed, or not applicable — which moves it to the asset's history, or the underlying data changed. Check the history first; if an outcome was wrong, retract it and the suggestion returns (Outcomes and History).",{"id":1941,"title":1942,"titles":1943,"content":1944,"level":444},"\u002Freference\u002Ffaq#why-doesnt-my-scoped-quirk-match-the-playbook","Why doesn't my scoped quirk match the playbook?",[263],"Scoped matching is strict about parentage. Unsafe Prototype-Chain Lookup scoped inside Node.js does not satisfy a requirement for the same quirk inside a different technology — even if the quirk name matches. Re-check where the requirement is anchored.",{"id":1946,"title":1947,"titles":1948,"content":1949,"level":444},"\u002Freference\u002Ffaq#is-the-nexus-engine-an-ai-can-it-find-bugs-for-me","Is the Nexus Engine an AI? Can it find bugs for me?",[263],"No. It is a deterministic, rule-based expert system — the same data always produces the same suggestions, with no model guessing in between. It cannot find what you have not modeled: unencoded threats are invisible by definition. It makes the knowledge you do encode impossible to forget.",{"id":1951,"title":1952,"titles":1953,"content":1954,"level":444},"\u002Freference\u002Ffaq#failed-or-not-applicable-whats-the-difference","Failed or not applicable — what's the difference?",[263],"Failed means you tested it and it did not work on this asset. Not applicable means the playbook is genuinely irrelevant here — you are not recording a failed test. Both retire the suggestion, but they say different things in the history.",{"id":1956,"title":1957,"titles":1958,"content":1959,"level":444},"\u002Freference\u002Ffaq#how-do-i-undo-a-recorded-outcome","How do I undo a recorded outcome?",[263],"Retract it from the asset's history. Retracting a success revokes the yields it granted and cascades through anything that depended on them (Yields and Primitives).",{"id":1961,"title":1962,"titles":1963,"content":1964,"level":444},"\u002Freference\u002Ffaq#why-cant-i-create-another-workspace","Why can't I create another workspace?",[263],"Workspace ownership is limited by plan: Free accounts own one workspace, Pro accounts up to five. Cloning creates a new workspace, so it counts too.",{"id":1966,"title":1967,"titles":1968,"content":1969,"level":444},"\u002Freference\u002Ffaq#how-do-ai-agents-access-my-workspace","How do AI agents access my workspace?",[263],"Through connections in Workspace Settings → Integrations — Pro feature, capped per member, scoped to the workspace, with capability toggles, expiry, revocation, and an audit trail.",{"id":237,"title":10,"titles":1971,"content":1972,"level":270},[],"Lookup material — the vocabulary, and the details behind the workflow.",{"id":1974,"title":1975,"titles":1976,"content":1977,"level":276},"\u002Freference#quick-lookups","Quick lookups",[10],"Glossary — every Nimbus Vault term, defined.Search the Workspace — the command center, and how to hunt horizontally.Search Syntax — every command-center filter, with examples.Settings — account vs. workspace settings, and plan limits.Dashboard Metrics — what each number means.FAQ — the questions that come up most.",{"id":1979,"title":1980,"titles":1981,"content":1982,"level":270},"\u002F","Nimbus Vault Docs",[],"Everything you need to run Nimbus Vault — from your first asset to playbook-driven exploitation.",{"id":1984,"title":1985,"titles":1986,"content":1987,"level":276},"\u002F#what-is-nimbus-vault","What is Nimbus Vault?",[1980],"Nimbus Vault is a structured workspace for ethical hackers. Instead of scattered notes, you build three things that compound: A target inventory — platforms, programs, and assets, with everything you observe attached where it belongs.A component library — the reusable building blocks of your targets: technologies, functionalities, gadgets, vectors, and quirks.A playbook library — capability recipes that describe how observed components combine into exploitable outcomes. The Nexus Engine connects the three. It is deterministic and rule-based — no AI guessing — matching your playbooks against what you have observed, surfacing ranked suggestions with the reasoning behind them, and building a proactive checklist of what to probe next.",{"id":1989,"title":472,"titles":1990,"content":1991,"level":276},"\u002F#where-to-start",[1980],"Getting started — create a workspace, seed your library, see your first suggestions.Workspace — scope, mapping, and collaboration.Components — the library and its five types.Playbooks and the Nexus Engine — how knowledge becomes suggestions.Methodology — CAVET and contextual hacking, the thinking behind the tooling.Tools — the MCP server and the browser extension.Glossary — every term in one place.",{"id":1993,"title":224,"body":1994,"description":1657,"extension":3095,"meta":3096,"navigation":26,"path":225,"pro":26,"seo":3097,"stem":226,"type":3098,"updatedAt":3099,"__hash__":3100},"docs\u002F6.tools\u002F1.mcp-server.md",{"type":1995,"value":1996,"toc":3076},"minimark",[1997,2001,2005,2013,2018,2025,2028,2032,2293,2297,2300,2303,2320,2323,2385,2388,2391,2398,2402,2473,2476,2530,2533,2619,2622,2696,2699,2759,2762,2796,2799,2831,2834,2860,2863,2872,2952,2955,2964,2967,2987,2991,2994,3023,3027,3030,3056,3059,3072],[1998,1999,1660],"h2",{"id":2000},"what-a-connection-does",[2002,2003,2004],"p",{},"A connection lets an AI agent work in your workspace on your behalf, with your access level — over the Model Context Protocol (MCP). The agent can read what you can read and do what you can do, scoped to that workspace and bounded by the capabilities you leave enabled on the connection.",[2002,2006,2007,2008,2012],{},"Everything below happens in ",[2009,2010,2011],"strong",{},"Workspace Settings → Integrations",". Every member can see the workspace's connections (name, owner, status, expiry) — transparency without secrets. Owners manage their own; admins can revoke any.",[2014,2015],"visual-placeholder",{"label":2016,"hint":2017},"Connections in Workspace Settings","Screenshot: Workspace Settings → Integrations tab showing the connections table with Name, Owner, Status, and Expiry columns",[2019,2020,2022],"callout",{"type":2021},"pro",[2002,2023,2024],{},"Agent connections are a Pro feature. Each member can hold up to 10 connections per workspace.",[1998,2026,1665],{"id":2027},"creating-a-connection",[2014,2029],{"label":2030,"hint":2031},"The create-connection dialog","Screenshot: New connection dialog with the name field and the 30 \u002F 90 \u002F 365 \u002F never expiry choices",[2033,2034,2035,2036,2035,2052,2035,2062,2035,2278],"steps",{},"\n  ",[2037,2038,2040],"step",{"title":2039},"New connection",[2002,2041,2042,2043,2047,2048,2051],{},"Open the Integrations tab and create one. Give it a name you will recognize later — ",[2044,2045,2046],"code",{},"Claude Code — laptop"," beats ",[2044,2049,2050],{},"test"," — and choose an expiry: 90 days by default, or 30 \u002F 90 \u002F 365 \u002F never.",[2037,2053,2055],{"title":2054},"Copy the token — once",[2002,2056,2057,2058,2061],{},"The connection token (",[2044,2059,2060],{},"nv_live_…",") is shown a single time. Copy it into your client before closing the dialog; if you lose it, rotate the connection and copy a fresh one.",[2037,2063,2065,2079,2133,2136],{"title":2064},"Wire up your client",[2002,2066,2067,2068,2071,2072,2071,2075,2078],{},"Pick your client and paste the pre-filled snippet — the dialog provides one for ",[2009,2069,2070],{},"Claude Code",", ",[2009,2073,2074],{},"Claude Desktop",[2009,2076,2077],{},"Cursor",", and a generic \"Other\" form. For Claude Code:",[2080,2081,2085],"pre",{"className":2082,"code":2083,"language":2084,"meta":1381,"style":1381},"language-bash shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","claude mcp add --transport http nimbus https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp \\\n  --header \"Authorization: Bearer nv_live_…\"\n","bash",[2044,2086,2087,2118],{"__ignoreMap":1381},[2088,2089,2091,2095,2099,2102,2105,2108,2111,2114],"span",{"class":2090,"line":270},"line",[2088,2092,2094],{"class":2093},"sBMFI","claude",[2088,2096,2098],{"class":2097},"sfazB"," mcp",[2088,2100,2101],{"class":2097}," add",[2088,2103,2104],{"class":2097}," --transport",[2088,2106,2107],{"class":2097}," http",[2088,2109,2110],{"class":2097}," nimbus",[2088,2112,2113],{"class":2097}," https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp",[2088,2115,2117],{"class":2116},"sTEyZ"," \\\n",[2088,2119,2120,2123,2127,2130],{"class":2090,"line":276},[2088,2121,2122],{"class":2097},"  --header",[2088,2124,2126],{"class":2125},"sMK4o"," \"",[2088,2128,2129],{"class":2097},"Authorization: Bearer nv_live_…",[2088,2131,2132],{"class":2125},"\"\n",[2002,2134,2135],{},"For JSON-based clients (Claude Desktop, Cursor):",[2080,2137,2141],{"className":2138,"code":2139,"language":2140,"meta":1381,"style":1381},"language-json shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","{\n  \"mcpServers\": {\n    \"nimbus\": {\n      \"type\": \"http\",\n      \"url\": \"https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp\",\n      \"headers\": { \"Authorization\": \"Bearer nv_live_…\" }\n    }\n  }\n}\n","json",[2044,2142,2143,2148,2166,2180,2204,2225,2260,2266,2272],{"__ignoreMap":1381},[2088,2144,2145],{"class":2090,"line":270},[2088,2146,2147],{"class":2125},"{\n",[2088,2149,2150,2153,2157,2160,2163],{"class":2090,"line":276},[2088,2151,2152],{"class":2125},"  \"",[2088,2154,2156],{"class":2155},"spNyl","mcpServers",[2088,2158,2159],{"class":2125},"\"",[2088,2161,2162],{"class":2125},":",[2088,2164,2165],{"class":2125}," {\n",[2088,2167,2168,2171,2174,2176,2178],{"class":2090,"line":444},[2088,2169,2170],{"class":2125},"    \"",[2088,2172,2173],{"class":2093},"nimbus",[2088,2175,2159],{"class":2125},[2088,2177,2162],{"class":2125},[2088,2179,2165],{"class":2125},[2088,2181,2183,2186,2190,2192,2194,2196,2199,2201],{"class":2090,"line":2182},4,[2088,2184,2185],{"class":2125},"      \"",[2088,2187,2189],{"class":2188},"sbssI","type",[2088,2191,2159],{"class":2125},[2088,2193,2162],{"class":2125},[2088,2195,2126],{"class":2125},[2088,2197,2198],{"class":2097},"http",[2088,2200,2159],{"class":2125},[2088,2202,2203],{"class":2125},",\n",[2088,2205,2207,2209,2212,2214,2216,2218,2221,2223],{"class":2090,"line":2206},5,[2088,2208,2185],{"class":2125},[2088,2210,2211],{"class":2188},"url",[2088,2213,2159],{"class":2125},[2088,2215,2162],{"class":2125},[2088,2217,2126],{"class":2125},[2088,2219,2220],{"class":2097},"https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp",[2088,2222,2159],{"class":2125},[2088,2224,2203],{"class":2125},[2088,2226,2228,2230,2233,2235,2237,2240,2242,2246,2248,2250,2252,2255,2257],{"class":2090,"line":2227},6,[2088,2229,2185],{"class":2125},[2088,2231,2232],{"class":2188},"headers",[2088,2234,2159],{"class":2125},[2088,2236,2162],{"class":2125},[2088,2238,2239],{"class":2125}," {",[2088,2241,2126],{"class":2125},[2088,2243,2245],{"class":2244},"swJcz","Authorization",[2088,2247,2159],{"class":2125},[2088,2249,2162],{"class":2125},[2088,2251,2126],{"class":2125},[2088,2253,2254],{"class":2097},"Bearer nv_live_…",[2088,2256,2159],{"class":2125},[2088,2258,2259],{"class":2125}," }\n",[2088,2261,2263],{"class":2090,"line":2262},7,[2088,2264,2265],{"class":2125},"    }\n",[2088,2267,2269],{"class":2090,"line":2268},8,[2088,2270,2271],{"class":2125},"  }\n",[2088,2273,2275],{"class":2090,"line":2274},9,[2088,2276,2277],{"class":2125},"}\n",[2037,2279,2281],{"title":2280},"First prompt",[2002,2282,2283,2284,2288,2289,2292],{},"Ask your agent: ",[2285,2286,2287],"em",{},"\"Use Nimbus to show my workspace context.\""," The first exchange flips the connection from ",[2009,2290,2291],{},"Never"," to recently used — proof the loop works.",[2014,2294],{"label":2295,"hint":2296},"Create, copy, connect, verify","Clip: creating a connection, copying the one-time nv_live_ token from the reveal state, then the connection row flipping from Never to a recent used timestamp after the client's first prompt",[1998,2298,1670],{"id":2299},"the-working-guide",[2002,2301,2302],{},"Every connection ships with Nimbus's operating methodology — the strict working guide Nimbus serves to agents. It is strict on purpose: the engine is deterministic, and an agent that reorders the work produces wrong records that suppress correct work later.",[2002,2304,2305,2306,2309,2310,2315,2316,2319],{},"It is delivered two ways: as MCP ",[2009,2307,2308],{},"server instructions"," (injected into the client's model context when the connection initializes) and as the ",[2009,2311,2312],{},[2044,2313,2314],{},"nimbus:\u002F\u002Fguide"," resource. ",[2044,2317,2318],{},"get_context"," points at it for clients that surface neither.",[2002,2321,2322],{},"The guide fixes one ordering:",[2324,2325,2326,2352,2358,2364,2374,2379],"ol",{},[2327,2328,2329,2332,2333,2335,2336,2339,2340,2343,2344,2347,2348,2351],"li",{},[2009,2330,2331],{},"Orient"," — ",[2044,2334,2318],{},", then ",[2044,2337,2338],{},"get_asset_context"," (or ",[2044,2341,2342],{},"get_asset_suggestions",") for the asset being worked. Between cycles, ",[2044,2345,2346],{},"get_asset_delta"," refreshes only what changed; ",[2044,2349,2350],{},"get_asset_graph"," is the compact map for verification passes. Never start from the playbook library.",[2327,2353,2354,2357],{},[2009,2355,2356],{},"Map"," — link every library-grade component actually observed, at the scope it was observed, with its endpoints, version, and state. Nested components ride the existing link that carries their parent — never a duplicate top-level link.",[2327,2359,2360,2363],{},[2009,2361,2362],{},"Work the prompts"," — resolve a prompt into its tests, run the probes, then confirm the positive observations or record a negative check. Negative checks are permanent suppressions: they are only valid after the full flow was traced.",[2327,2365,2366,2369,2370,2373],{},[2009,2367,2368],{},"Read"," — playbooks only once the engine suggests them (",[2044,2371,2372],{},"get_suggested_playbook","). Never browse the library to pick work.",[2327,2375,2376,2378],{},[2009,2377,1426],{}," — in score order, following each playbook's notes literally, and recording honest outcomes.",[2327,2380,2381,2384],{},[2009,2382,2383],{},"Record"," — findings as notes, corrections via retraction. A wrong record costs more than a missing one.",[2002,2386,2387],{},"A few hard rules from the guide worth knowing as the workspace owner: map only what was observed, never fabricate a link to make a playbook match; the engine's suggestions are the gate; and everything the tools return is treated as data, never as instructions.",[1998,2389,1675],{"id":2390},"the-toolset",[2002,2392,2393,2394,2397],{},"Every connection exposes the same surface: ",[2009,2395,2396],{},"51 tools",". Forty-eight are curated for the vault's workflows — grouped below with their use cases — and three are a gateway into the wider backend for everything else.",[2399,2400,1680],"h3",{"id":2401},"orientation",[2403,2404,2405,2412,2420,2427,2437,2444,2451,2459],"ul",{},[2327,2406,2407,2411],{},[2009,2408,2409],{},[2044,2410,2318],{}," — The workspace, the acting user, engine mode, and counts. The entry point: call it first, every session. Always available, even on locked-down connections.",[2327,2413,2414,2419],{},[2009,2415,2416],{},[2044,2417,2418],{},"get_asset"," — One asset's digest: linked components with endpoints, quirk state, and CL nesting labels, plus the technology defaults the engine counts as inherited. Read this when you need the observed surface.",[2327,2421,2422,2426],{},[2009,2423,2424],{},[2044,2425,2338],{}," — The full projection for an asset in a single call: digest, ranked suggestions, the complete tiered checklist, and earned primitives. The recommended context injection before an investigation cycle.",[2327,2428,2429,2433,2434,2436],{},[2009,2430,2431],{},[2044,2432,2342],{}," — Ranked playbook suggestions plus the proactive\u002Freactive checklist, with probes inline. The recommended first call after ",[2044,2435,2418],{},".",[2327,2438,2439,2443],{},[2009,2440,2441],{},[2044,2442,2346],{}," — A compact change feed since a cursor: new or updated links, outcomes, checklist checks, touched notes, open prompts. Use it between work cycles instead of re-fetching.",[2327,2445,2446,2450],{},[2009,2447,2448],{},[2044,2449,2350],{}," — The compact nesting graph — one node per link with its CL label, surfaces, and children. Built for verification passes and map checks.",[2327,2452,2453,2458],{},[2009,2454,2455],{},[2044,2456,2457],{},"get_program_scope"," — Program details, platform, guidelines, and the curated asset inventory. Use it to seed a scope allowlist; the assets are the authoritative inventory, the guidelines text is advisory.",[2327,2460,2461,2466,2467,2472],{},[2009,2462,2463],{},[2044,2464,2465],{},"list_programs"," \u002F ",[2009,2468,2469],{},[2044,2470,2471],{},"list_assets"," — The workspace's programs and a program's assets, wildcards and children included.",[2399,2474,1685],{"id":2475},"mapping-and-capture",[2403,2477,2478,2486,2494,2506,2514,2522],{},[2327,2479,2480,2485],{},[2009,2481,2482],{},[2044,2483,2484],{},"link_component_to_asset"," — Confirm a single observed component, with endpoints, version, and state. Endpoints are observation surfaces: the page route or concrete URL where it was seen, never the API route the feature calls. Nested children ride the parent's instances.",[2327,2487,2488,2493],{},[2009,2489,2490],{},[2044,2491,2492],{},"link_components_to_asset"," — The recon-dump batch: up to 25 components in one transactional call. Existing links are updated in place, never duplicated — retrying after a transport error is safe.",[2327,2495,2496,2501,2502,2505],{},[2009,2497,2498],{},[2044,2499,2500],{},"create_asset"," — Add an asset to a program; ",[2044,2503,2504],{},"Wildcard"," types act as containers with concrete children beneath them.",[2327,2507,2508,2513],{},[2009,2509,2510],{},[2044,2511,2512],{},"update_asset"," — Patch an asset's name, type, URL, priority, tags, or description.",[2327,2515,2516,2521],{},[2009,2517,2518],{},[2044,2519,2520],{},"import_assets"," — Batch-create up to 500 assets from a scope list. Duplicates are reported, never overwritten.",[2327,2523,2524,2529],{},[2009,2525,2526],{},[2044,2527,2528],{},"reconcile_technology_defaults"," — Materialize the inherited technology defaults onto an asset's technology links — the same reconciliation the web UI runs after link changes.",[2399,2531,1690],{"id":2532},"prompts-and-checklists",[2403,2534,2535,2543,2551,2559,2567,2575,2583,2595,2603,2611],{},[2327,2536,2537,2542],{},[2009,2538,2539],{},[2044,2540,2541],{},"get_asset_checklist"," — The full proactive and reactive checklist. Concrete prompts carry their probes inline; category\u002Ftag prompts carry a resolution block.",[2327,2544,2545,2550],{},[2009,2546,2547],{},[2044,2548,2549],{},"get_checklist_summary"," — A planning rollup: prompt count per playbook with matched\u002Fmissing\u002Ftotal requirement counts, plus objective counts. Use it to plan a sweep.",[2327,2552,2553,2558],{},[2009,2554,2555],{},[2044,2556,2557],{},"resolve_checklist_prompt"," — Turn one prompt into actionable tests in a single call, plus the exact confirmation recipe.",[2327,2560,2561,2566],{},[2009,2562,2563],{},[2044,2564,2565],{},"explain_prompt"," — Why a prompt exists: the playbook(s), the target component, expected vs recorded polarity, and what closes it.",[2327,2568,2569,2574],{},[2009,2570,2571],{},[2044,2572,2573],{},"confirm_checklist_prompt"," — Clear a prompt by linking the observed component at the correct scope — on the existing link that already carries the parent. Returns a structured reason when nothing was linked.",[2327,2576,2577,2582],{},[2009,2578,2579],{},[2044,2580,2581],{},"confirm_checklist_prompts"," — The bulk sweep: up to 10 confirmations per call, each with its own result.",[2327,2584,2585,2590,2591,2594],{},[2009,2586,2587],{},[2044,2588,2589],{},"check_prompt"," — Record a ",[2009,2592,2593],{},"negative"," result: the probe ran and found nothing, so the prompt stops resurfacing permanently. Only valid after tracing the full flow for component-level children.",[2327,2596,2597,2602],{},[2009,2598,2599],{},[2044,2600,2601],{},"check_prompts"," — Batch up to 50 negative checks.",[2327,2604,2605,2610],{},[2009,2606,2607],{},[2044,2608,2609],{},"check_objective"," — Mark a reactive objective complete, so it stops resurfacing and lands in the asset's history.",[2327,2612,2613,2618],{},[2009,2614,2615],{},[2044,2616,2617],{},"get_probes"," — The test recipes for concrete component targets, or for the candidates resolved from a category\u002Ftag group.",[2399,2620,1695],{"id":2621},"suggestions-and-playbooks",[2403,2623,2624,2632,2640,2647,2664,2672,2680,2688],{},[2327,2625,2626,2631],{},[2009,2627,2628],{},[2044,2629,2630],{},"get_asset_playbook_suggestions"," — The ranked list with score, confidence, and matched components.",[2327,2633,2634,2639],{},[2009,2635,2636],{},[2044,2637,2638],{},"explain_suggestion"," — Why a playbook is or is not suggested: score breakdown when it is; the exact blocking prompts when it is not. Works even when direct read is disabled.",[2327,2641,2642,2646],{},[2009,2643,2644],{},[2044,2645,2372],{}," — The suggestion-gated read: requirements with resolved names, the note bodies (the methodology), and the yield configuration. Only allowed for playbooks currently suggested for the asset, or present in its outcome history.",[2327,2648,2649,2466,2654,2659,2660,2663],{},[2009,2650,2651],{},[2044,2652,2653],{},"get_playbook",[2009,2655,2656],{},[2044,2657,2658],{},"list_playbooks"," — The raw library reads, gated by the ",[2009,2661,2662],{},"Read playbooks directly"," capability. Turn that capability off to force the suggestion-driven path.",[2327,2665,2666,2671],{},[2009,2667,2668],{},[2044,2669,2670],{},"find_assets_for_playbook"," — The reverse ranking: which assets a playbook fits, scored by the same engine.",[2327,2673,2674,2679],{},[2009,2675,2676],{},[2044,2677,2678],{},"record_outcome"," — Record success, failed, or not applicable on a suggested playbook. Success grants the declared yields; prompted yields take their discovery endpoint. The playbook must currently be suggested.",[2327,2681,2682,2687],{},[2009,2683,2684],{},[2044,2685,2686],{},"retract_outcome"," — Revert a recorded outcome: granted yields are revoked and dependent successes cascade-revert, all reported.",[2327,2689,2690,2695],{},[2009,2691,2692],{},[2044,2693,2694],{},"get_asset_history"," — The asset's outcomes and checklist history.",[2399,2697,1700],{"id":2698},"library",[2403,2700,2701,2709,2717,2727,2735,2743,2751],{},[2327,2702,2703,2708],{},[2009,2704,2705],{},[2044,2706,2707],{},"get_component_catalog"," — The whole library in one call — ids, names, categories, tags. Use it to constrain extraction to entries that actually exist before analysing or bulk-linking.",[2327,2710,2711,2716],{},[2009,2712,2713],{},[2044,2714,2715],{},"list_components"," — One component type, optionally filtered by text.",[2327,2718,2719,2724,2725,2436],{},[2009,2720,2721],{},[2044,2722,2723],{},"list_component_group"," — Resolve a category, category+tag combo, or tag into its concrete members — the step between tier-2 prompts and ",[2044,2726,2617],{},[2327,2728,2729,2734],{},[2009,2730,2731],{},[2044,2732,2733],{},"get_component"," — A component with its notespace: linked assets and playbooks, objectives, and probes.",[2327,2736,2737,2742],{},[2009,2738,2739],{},[2044,2740,2741],{},"create_component"," — Create a library entry. Technologies auto-fill from the presets catalog; a same-name entry is returned as-is instead of duplicated, so agents link the existing one.",[2327,2744,2745,2750],{},[2009,2746,2747],{},[2044,2748,2749],{},"search_technology_presets"," — Search the canonical technology catalog (the same fork the web library uses) and create with the preset's exact name, category, description, and logo.",[2327,2752,2753,2758],{},[2009,2754,2755],{},[2044,2756,2757],{},"get_technology_defaults"," — The quirks, vectors, and gadgets a technology declares, split into what the engine assumes automatically and what waits for per-asset adoption.",[2399,2760,1705],{"id":2761},"search-and-coverage",[2403,2763,2764,2772,2780,2788],{},[2327,2765,2766,2771],{},[2009,2767,2768],{},[2044,2769,2770],{},"search"," — One query across assets, components, playbooks, and notes.",[2327,2773,2774,2779],{},[2009,2775,2776],{},[2044,2777,2778],{},"find_assets_by_component"," — Every asset that links a given component, exact links only, with endpoints and quirk state.",[2327,2781,2782,2787],{},[2009,2783,2784],{},[2044,2785,2786],{},"get_coverage"," — Coverage and blind spots: observed components no playbook references, or the workspace's per-asset coverage, worst first.",[2327,2789,2790,2795],{},[2009,2791,2792],{},[2044,2793,2794],{},"audit_links"," — The link-graph integrity audit: dangling targets, broken nested references, orphaned notespaces, endpointless synthetic instances. Run it after deletions.",[2399,2797,1710],{"id":2798},"notes",[2403,2800,2801,2809,2817],{},[2327,2802,2803,2808],{},[2009,2804,2805],{},[2044,2806,2807],{},"add_note"," — Add a markdown note to an asset, component, technology, or playbook notespace — findings, observations, follow-ups.",[2327,2810,2811,2816],{},[2009,2812,2813],{},[2044,2814,2815],{},"list_asset_notes"," — Keyword-search an asset's notes by title and preview before writing a duplicate.",[2327,2818,2819,2824,2825,2827,2828,2830],{},[2009,2820,2821],{},[2044,2822,2823],{},"read_note"," — The full body of a note by id. Playbook-note reads are gated by ",[2009,2826,2662],{},"; when it is off, ",[2044,2829,2372],{}," already returns note bodies.",[2399,2832,1715],{"id":2833},"the-gateway",[2403,2835,2836,2844,2852],{},[2327,2837,2838,2843],{},[2009,2839,2840],{},[2044,2841,2842],{},"list_functions"," — The backend functions this connection may call, with scope and destructiveness. Always filtered by the connection's capabilities.",[2327,2845,2846,2851],{},[2009,2847,2848],{},[2044,2849,2850],{},"get_function_spec"," — One function's argument JSON Schema, kind, and destructiveness — check before calling.",[2327,2853,2854,2859],{},[2009,2855,2856],{},[2044,2857,2858],{},"call_function"," — Call any allowed backend function directly: workspace ids are injected, entity ids are fenced to the workspace, and the same capability policy applies. This is how an agent reaches operations beyond the curated 48 — including destructive ones, which should be confirmed before calling.",[1998,2861,1720],{"id":2862},"capabilities-what-the-agent-may-do",[2002,2864,2865,2866,2869,2870,2436],{},"Tools are grouped into ",[2009,2867,2868],{},"20 capabilities"," — the human-facing permission units you toggle per connection. Every capability maps to explicit backend functions, and the gateway enforces it on every call, including calls made through ",[2044,2871,2858],{},[2873,2874,2875,2888],"table",{},[2876,2877,2878],"thead",{},[2879,2880,2881,2885],"tr",{},[2882,2883,2884],"th",{},"Group",[2882,2886,2887],{},"Capabilities",[2889,2890,2891,2902,2912,2922,2932,2942],"tbody",{},[2879,2892,2893,2899],{},[2894,2895,2896],"td",{},[2009,2897,2898],{},"Observe",[2894,2900,2901],{},"Read workspace data",[2879,2903,2904,2909],{},[2894,2905,2906],{},[2009,2907,2908],{},"Recon & capture",[2894,2910,2911],{},"Create and update assets · Manage programs and platforms · Link components to assets",[2879,2913,2914,2919],{},[2894,2915,2916],{},[2009,2917,2918],{},"Nexus loop",[2894,2920,2921],{},"Read playbooks directly · Record outcomes and checklist progress",[2879,2923,2924,2929],{},[2894,2925,2926],{},[2009,2927,2928],{},"Knowledge authoring",[2894,2930,2931],{},"Create library components · Update library components · Write notes · Author checklist objectives and probes · Author playbooks",[2879,2933,2934,2939],{},[2894,2935,2936],{},[2009,2937,2938],{},"Destructive",[2894,2940,2941],{},"Delete assets · Delete library components · Delete notes · Delete objectives and probes · Delete playbooks and yields · Retract recorded outcomes · Delete programs and platforms",[2879,2943,2944,2949],{},[2894,2945,2946],{},[2009,2947,2948],{},"Administration",[2894,2950,2951],{},"Workspace administration (destructive) · Read audit logs",[2002,2953,2954],{},"Everything is enabled by default — the policy is a deny-list. Uncheck a capability and every function mapped to it is blocked; disabled capabilities also hide their tools, so the agent never plans around something it cannot call.",[2002,2956,2957,2958,2960,2961,2963],{},"Two deliberate exceptions: ",[2044,2959,2318],{}," is always available (baseline orientation; its reads degrade gracefully rather than failing), and ",[2044,2962,2823],{}," stays available with its playbook-note path gated per call.",[2002,2965,2966],{},"Policies worth considering when you narrow a connection:",[2403,2968,2969,2975,2981],{},[2327,2970,2971,2972,2974],{},"Turn ",[2009,2973,2662],{}," off to keep the agent on the suggestion-gated path — it still reads every playbook the engine surfaces for an asset.",[2327,2976,2977,2978,2980],{},"Keep the ",[2009,2979,2938],{}," groups off unless the agent is doing deliberate housekeeping; deletions cascade and are not reversible.",[2327,2982,2983,2986],{},[2009,2984,2985],{},"Workspace administration"," covers membership, invites, sharing, cloning, and deletion — rarely something an agent should hold.",[2014,2988],{"label":2989,"hint":2990},"Capability toggles","Screenshot: a connection's capability policy detail showing the grouped toggles, a couple unchecked, and the 'N of 20 capabilities disabled' summary",[1998,2992,1725],{"id":2993},"managing-connections",[2403,2995,2996,3002,3008,3014,3020],{},[2327,2997,2998,3001],{},[2009,2999,3000],{},"Status chips"," — Active, Expired, or Revoked, at a glance.",[2327,3003,3004,3007],{},[2009,3005,3006],{},"Rename \u002F renew \u002F rotate"," — lifecycle actions for the owner. Rotate immediately if a token leaks.",[2327,3009,3010,3013],{},[2009,3011,3012],{},"Revoke"," — owners revoke their own; admins can revoke any. Revocation takes effect at the next exchange, and live sessions end shortly after.",[2327,3015,3016,3019],{},[2009,3017,3018],{},"Delete"," — removes revoked or expired rows permanently.",[2327,3021,3022],{},"Leaving or being removed from a workspace deletes your connections for it.",[2014,3024],{"label":3025,"hint":3026},"Connection status chips","Screenshot: connection rows showing the Active, Expired, and Revoked status chips with the owner actions menu",[1998,3028,1730],{"id":3029},"security-model",[2403,3031,3032,3038,3044,3050],{},[2327,3033,3034,3037],{},[2009,3035,3036],{},"Workspace-scoped."," A token reaches one workspace and nothing else.",[2327,3039,3040,3043],{},[2009,3041,3042],{},"No secret at rest."," The raw token is never stored or logged — only a hash, used to mint short-lived sessions.",[2327,3045,3046,3049],{},[2009,3047,3048],{},"Expiry by default."," Connections come with an end date unless you deliberately choose otherwise.",[2327,3051,3052,3055],{},[2009,3053,3054],{},"Audited."," Connecting, revoking, and every write the agent makes are recorded in the workspace's audit log.",[1998,3057,337],{"id":3058},"whats-next",[2403,3060,3061,3067],{},[2327,3062,3063,3066],{},[3064,3065,138],"a",{"href":139}," — the human side of working together.",[2327,3068,3069,3071],{},[3064,3070,247],{"href":248}," — the same surface, driven by you.",[3073,3074,3075],"style",{},"html pre.shiki code .sBMFI, html code.shiki .sBMFI{--shiki-light:#E2931D;--shiki-default:#FFCB6B;--shiki-dark:#FFCB6B}html pre.shiki code .sfazB, html code.shiki .sfazB{--shiki-light:#91B859;--shiki-default:#C3E88D;--shiki-dark:#C3E88D}html pre.shiki code .sTEyZ, html code.shiki .sTEyZ{--shiki-light:#90A4AE;--shiki-default:#EEFFFF;--shiki-dark:#BABED8}html pre.shiki code .sMK4o, html code.shiki .sMK4o{--shiki-light:#39ADB5;--shiki-default:#89DDFF;--shiki-dark:#89DDFF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .spNyl, html code.shiki .spNyl{--shiki-light:#9C3EDA;--shiki-default:#C792EA;--shiki-dark:#C792EA}html pre.shiki code .sbssI, html code.shiki .sbssI{--shiki-light:#F76D47;--shiki-default:#F78C6C;--shiki-dark:#F78C6C}html pre.shiki code .swJcz, html code.shiki .swJcz{--shiki-light:#E53935;--shiki-default:#F07178;--shiki-dark:#F07178}",{"title":1381,"searchDepth":444,"depth":444,"links":3077},[3078,3079,3080,3081,3091,3092,3093,3094],{"id":2000,"depth":276,"text":1660},{"id":2027,"depth":276,"text":1665},{"id":2299,"depth":276,"text":1670},{"id":2390,"depth":276,"text":1675,"children":3082},[3083,3084,3085,3086,3087,3088,3089,3090],{"id":2401,"depth":444,"text":1680},{"id":2475,"depth":444,"text":1685},{"id":2532,"depth":444,"text":1690},{"id":2621,"depth":444,"text":1695},{"id":2698,"depth":444,"text":1700},{"id":2761,"depth":444,"text":1705},{"id":2798,"depth":444,"text":1710},{"id":2833,"depth":444,"text":1715},{"id":2862,"depth":276,"text":1720},{"id":2993,"depth":276,"text":1725},{"id":3029,"depth":276,"text":1730},{"id":3058,"depth":276,"text":337},"md",{},{"title":224,"description":1657},"guide","2026-10-06","88GAh4h1qO-fuvJWxQOWmVdHqCh1xJKG-M-LoILPXqA",[3102,3103],{"title":10,"path":218,"stem":222,"description":1784,"children":-1},{"title":228,"path":229,"stem":230,"description":1739,"children":-1},1791641375187]