[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"kb-article-designing-secure-agentic-ai-how-cisco-s-foundry-specification-can-standardize-open-source-defenses-en":3,"ArticleBody_AucpSDe09vUlvBLmeSuXuJXMASuP6vmJfKooiRyg0":204},{"article":4,"relatedArticles":174,"locale":62},{"id":5,"title":6,"slug":7,"content":8,"htmlContent":9,"excerpt":10,"category":11,"tags":12,"metaDescription":10,"wordCount":13,"readingTime":14,"publishedAt":15,"sources":16,"sourceCoverage":54,"transparency":56,"seo":59,"language":62,"featuredImage":63,"featuredImageCredit":64,"isFreeGeneration":68,"trendSlug":69,"niche":70,"geoTakeaways":73,"geoFaq":82,"entities":92},"6a0e384aa83199a612324341","Designing Secure Agentic AI: How Cisco’s Foundry Specification Can Standardize Open-Source Defenses","designing-secure-agentic-ai-how-cisco-s-foundry-specification-can-standardize-open-source-defenses","Agentic AI is moving from chat windows into pipelines that touch code, infrastructure, and production data. These systems can perceive, plan, act with tools, and learn from memory with limited human supervision, which fundamentally raises the blast radius of any failure or compromise.[1]  \n\nVendors are reacting:  \n\n- [Databricks](\u002Fentities\u002F6a0d89e607a4fdbfcf5e8152-databricks) added Agentic AI as the 13th component in its AI Security Framework (DASF v3.0), with 35 new risks and 6 mitigation controls dedicated to agents.[9]  \n- [OpenAI](\u002Fentities\u002F6a0bb8b01f0b27c1f4270251-openai)’s Daybreak and [CrowdStrike](\u002Fentities\u002F69ea7cace1ca17caac372eab-crowdstrike)’s AgentWorks both treat agents as first-class security subjects, not just UX layers on top of LLMs.[4][7]  \n\nCisco’s open-source Foundry specification is emerging as a potential common language for defining how agents are structured, governed, and defended. Foundry-style specifications can standardize how we describe agent capabilities, tool surfaces, memory behavior, and observability—much like DASF’s Agentic AI Extension standardizes risk taxonomy.[9]  \n\n💡 **Orientation:** This article treats Foundry as a reference design. We position it among existing frameworks, infer core principles, walk through a reference architecture, and outline how to test and govern “Foundry-compliant” agent stacks in practice.\n\n---\n\n## 1. The security problem: why agentic AI needs a formal specification\n\nAgentic AI goes beyond classic prompt–response models. Instead of “answer this question,” we now have systems that:[1]  \n\n- Decompose goals into sub-tasks  \n- Call external tools and APIs  \n- Coordinate with other agents  \n- Persist and update long-term memory  \n\nThey operate autonomously across a perception → reasoning\u002Fplanning → action → learning loop using LLMs and other ML components.[1]  \n\n⚠️ **Risk shift:** The concern moves from “Did the model hallucinate?” to “What can the agent *do* if it’s wrong—or if it’s compromised?”[9]\n\n### Agentic AI in formal security frameworks\n\nDatabricks formalized this shift by extending DASF v3.0 with a dedicated Agentic AI component:[9]  \n\n- **13th system component:** Agentic AI  \n- **35 new agent-specific risks:** memory, planning, tool use, and communication[9]  \n- **6 new mitigation controls:** least privilege, sandboxing, human supervision, MCP hardening, and more[9]  \n\nThis treats autonomy as a fundamentally new risk surface that needs its own control plane, not just optional checks on chatbots.\n\n### High-privilege [SOC](\u002Fentities\u002F6a0be90a1f0b27c1f427162f-soc) workflows already depend on agents\n\nSecurity operations centers are wiring agents into SIEM and SOAR workflows.[3] Typical pattern:  \n\n- Ingest SIEM alerts  \n- Enrich with asset, identity, and threat-intel data  \n- Propose classifications and next steps  \n- Trigger SOAR playbooks for low-risk actions  \n\nIn one prototype, a triage agent silently downgraded noisy alerts. A parsing error on a rare alert type suppressed critical notifications from one [EDR](\u002Fentities\u002F69ea7cace1ca17caac372eb2-edr) source; only a human noticing fewer cases revealed the problem.[3]  \n\n➡️ **Lesson:** Silent, automated failures in high-privilege environments require a formal spec with built-in guardrails and monitoring.\n\n### Dedicated agentic security platforms and early-by-design moves\n\nSecurity vendors are building agent-centric platforms:  \n\n- **[CrowdStrike AgentWorks](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002F2024_CrowdStrike-related_IT_outages)** – lets SOC teams design, test, and deploy agents into [Falcon](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FFalcon), with governance, controls, and multi-model support ([Claude](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FClaude), GPT, [Nemotron](\u002Fentities\u002F6a0a73ff1f0b27c1f426a60e-nemotron)).[4]  \n- **OpenAI Daybreak** – wraps GPT‑5.5 variants and [Codex Security](\u002Fentities\u002F6a0b9b4f1f0b27c1f426f90a-codex-security) into a stack that embeds security analysis into SDLC: code review, threat modeling, patch generation, sandbox testing.[7][8]  \n\nDaybreak’s stance: security must be built in from the first lines of code, not bolted on later.[7]  \n\n💼 **Implication for Foundry:** Cisco’s open-source Foundry spec can be the vendor-neutral counterpart to these platforms: a shared schema for agent capabilities, tool wiring, permissions, and governance that any cloud, on-prem, or hybrid implementation can adopt.[9]\n\n---\n\n## 2. Situating Cisco’s Foundry among agentic AI and security frameworks\n\n### What “agentic AI” means for Foundry\n\nIn the Foundry context, “agentic AI” refers to autonomous systems that combine LLMs, other ML models, and external tools to complete complex tasks with minimal supervision.[1][2] They:  \n\n- Maintain internal state and memory  \n- Plan multi-step workflows  \n- Call APIs, databases, and runtimes  \n- Learn from past interactions  \n\nThis aligns with open-source views of agents as chaining perception, decision, and action rather than single-shot inferences.[2]\n\n### Open-source agents vs proprietary platforms\n\nOpen-source stacks and specs (like Foundry) imply:[2]  \n\n- **Inspectable code\u002Fconfigs:** audit, extend, or fork flows as needed  \n- **Deployment freedom:** on-prem, private cloud, hybrid; easier sovereignty\u002Fcompliance  \n- **Governance responsibility:** you own permissions, logging, and incident response  \n\nTrade-off: deep control and alignment with your infra, but you inherit operational burden and must enforce controls yourself.  \n\nBy contrast, AgentWorks and Daybreak provide managed environments with strong embedded guardrails but limited portability.[4][7]\n\n### Mapping Foundry to DASF’s Agentic AI Extension\n\nDatabricks’ Agentic AI Extension is a useful checklist for what any spec should cover:[9]  \n\n- Risk catalog for planning, memory, tool use, multi-agent communication  \n- Controls: least privilege, sandboxing, human-in-the-loop review, MCP hardening[9]  \n- Guidance for mapping every agent, tool, and integration to these risks[9]  \n\nA Foundry spec can mirror this: define components, enumerate threats per component, and attach control families (authz, isolation, monitoring, fail-safes).\n\n### Foundry vs Daybreak and heterogeneous ecosystems\n\nDaybreak is a vertically integrated, managed stack combining GPT‑5.5 and Codex Security for general, defensive, and offensive cyber workflows.[7][8] Suitable for organizations that want one vendor to control models, tools, and sandboxing.  \n\nFoundry targets portability: a blueprint that can run across clouds and stacks, including on-prem and hybrid scenarios like the OpenAI–Dell Codex partnership.[5] That partnership emphasizes deploying “where the enterprise data already resides,” with sovereignty and residency as core design constraints.[5]  \n\nSecurity vendors are also embedding agent design studios (AgentWorks) inside SOC platforms, with multi-model support and SOAR interoperability.[4] Any Foundry-style spec must therefore assume:[4][5][9]  \n\n- Multiple LLM providers  \n- Mixed on-prem\u002Fcloud tools  \n- Cross-vendor trust and data boundaries  \n\n📊 **Mini-conclusion:** Against DASF, Daybreak, AgentWorks, and Codex-on-Dell, Foundry’s distinctive role is to define a vendor-neutral *schema* for secure agent behavior that can move across heterogeneous environments.[4][5][9]\n\n---\n\n## 3. Core principles likely defined in Cisco’s Foundry agentic AI security spec\n\n### 3.1 Formalizing the agent lifecycle\n\nA mature spec should model the full lifecycle explicitly:[1][2]  \n\n1. **Perception** – ingest text, events, logs, metrics  \n2. **Reasoning \u002F planning** – decide on a course of action  \n3. **Action via tools** – call APIs, execute code, update systems  \n4. **Memory** – read\u002Fwrite long-term state  \n\nOpen-source guidance stresses that production agents must make these phases inspectable and auditable, not hide them inside opaque prompts.[2]  \n\n⚡ **Spec expectation:** Foundry should require explicit interfaces, policies, and logs for each phase, rather than “magic” inside a single LLM call.\n\n### 3.2 Tool and memory risks as first-class citizens\n\nDASF’s Agentic AI Extension treats tool ecosystems and MCP-based integrations as major attack surfaces.[9] Risks include:[9]  \n\n- Prompt injection leading to dangerous API calls  \n- Escalation via overly broad tool scopes  \n- Cross-tenant or cross-environment data exfiltration  \n\nA Foundry spec should therefore:[9]  \n\n- Define per-tool scopes and least-privilege defaults  \n- Mandate sandboxing for high-risk tools (code execution, infra changes)  \n- Set policies for memory retention, redaction, and access control  \n\n### 3.3 SOC-embedded agent principles\n\nFor SOC use cases (SIEM triage, enrichment, SOAR orchestration), the spec should define **tiers of authority**:[3]  \n\n- **Read-only analysis:** log\u002Fasset queries, scoring, explanations  \n- **Low-risk automation:** ticket enrichment, tagging, suggested playbooks  \n- **High-impact response:** firewall changes, account lockdowns, EDR actions  \n\nSome SOCs already prohibit agents from closing incidents or performing containment without explicit, logged human approval—even at high confidence—to prevent large-scale, wrongheaded actions.[3]\n\n### 3.4 Security-by-design in development workflows\n\nDaybreak’s Codex Security analyzes codebases, builds editable threat models, and tests patches in sandboxed environments before recommending merges.[7][8] A Foundry-aligned spec should:[7][8]  \n\n- Treat code and infra analysis as standard agent patterns  \n- Require sandboxed test environments for any code-modifying agent  \n- Encourage machine-readable evidence (test logs, exploit traces) for audits  \n\n### 3.5 Guardrails, ethics, and limitations\n\nGuardrail frameworks (Weights & Biases Guardrails, NVIDIA NeMo Guardrails, nexos.ai, and others) enforce behavioral constraints, detect PII leakage, moderate tool calls, and manage compliance.[6]  \n\nA Foundry spec should codify:[3][6]  \n\n- Mandatory risk assessment and monitoring hooks  \n- Policy-based blocking of specific tool calls or data flows  \n- Documentation of model biases and limitations, especially in SOC contexts  \n\n💡 **Mini-conclusion:** Across these principles, agents are treated like critical software components—with explicit lifecycle, threat models, and guardrails—not “smart prompts.”[2][6][9]\n\n---\n\n## 4. Reference architecture: implementing a Foundry-compliant secure agent stack\n\n### 4.1 Layered architecture\n\nA practical mental model:[1][2][3][4][5][9]  \n\n1. **LLM\u002FModel layer** – GPT, Claude, Nemotron, open-source LLMs[4]  \n2. **Agent core** – planner, memory manager, tool orchestrator[1][2]  \n3. **Security substrate (Foundry layer)** – policies, authorization, logging, guardrails[9]  \n4. **Integration layer** – SIEM, SOAR, ticketing, CI\u002FCD, data platforms[3][5]  \n\nCrowdStrike’s AgentWorks already shows pluggable model layers under a common governance umbrella; Foundry should formalize this separation so LLMs can be swapped without redoing security controls.[4]\n\n### 4.2 Control plane and governance APIs\n\nFor an open-source agent stack, the control plane should expose:[2]  \n\n- Policy definitions per agent and tool  \n- Audit logs for every tool call and memory write  \n- Versioning for prompts, workflows, and policies  \n\nExample YAML-style Foundry policy:\n\n```yaml\nagent: soc-triage\npermissions:\n  tools:\n    - name: query_siem\n      scope: read_only\n      max_rows: 5000\n    - name: trigger_soar_playbook\n      scope: restricted\n      require_human_approval: true\nmemory:\n  retention_days: 30\n  pii_redaction: enabled\nguardrails:\n  provider: nemo\n  blocks:\n    - data_exfiltration\n    - prompt_injection\n```\n\nThis is the level of explicitness a spec should encourage for secure operations.[2][6][9]\n\n### 4.3 On‑prem and hybrid patterns\n\nThe OpenAI–Dell Codex integration illustrates how agents can run close to enterprise data on Dell AI Data Platform and Dell AI Factory, keeping inference and context within the customer perimeter.[5] Foundry-aligned deployments can:[2][5]  \n\n- Self-host the agent runtime in a data center or VPC  \n- Connect to local data platforms and observability stacks  \n- Route only minimal signals to external LLM APIs under strict policies  \n\n📊 **Compliance angle:** This topology directly supports sovereignty and residency requirements common in European and regulated sectors.[2][5]\n\n### 4.4 SOC-centric deployment example\n\nA Foundry-compliant SOC agent stack might:[3][6]  \n\n- Ingest SIEM alerts via streaming  \n- Enrich alerts with CMDB, IAM, and threat-intel data  \n- Apply guardrails to prevent direct destructive actions  \n- Surface suggested triage decisions in the analyst console  \n- Trigger only low-risk SOAR tasks (tagging, ticket creation) automatically  \n\nSOC agent guides emphasize including architecture diagrams, performance metrics, and operational guardrails—elements a Foundry spec should require in deployment documentation.[3]\n\n### 4.5 DevSecOps workflow with sandboxed agents\n\nInspired by Daybreak, a secure development workflow can:[7][8]  \n\n1. Scan codebases and build an editable threat model  \n2. Identify realistic attack paths and risky dependencies  \n3. Propose code\u002Fconfig changes  \n4. Test changes in a sandbox that attempts known exploits  \n5. Export evidence and results for human review before merges  \n\n⚠️ **Non-negotiable:** Agents never write directly to production; changes flow through CI\u002FCD with standard approvals.[7][8]\n\n### 4.6 Guardrail layer integration\n\nGuardrail products (W&B Guardrails, NeMo Guardrails, nexos.ai) can act as a pre-execution filter for prompts, tool outputs, and planned actions.[6]  \n\nExample orchestration:\n\n```python\nplan = agent.plan(observation)\nvalidated_plan = guardrails.validate(plan)\nif not validated_plan.approved:\n    log_and_alert(validated_plan.issues)\nelse:\n    agent.execute(validated_plan)\n```\n\nThis pattern helps catch risky tool invocations before they hit critical systems.[6][9]\n\n---\n\n## 5. Testing, guardrails, and evaluation for Foundry-style agentic AI\n\n### 5.1 Testing the full perception–reason–act loop\n\nOpen-source reliability work stresses that single-prompt unit tests are insufficient.[2] You must test the complete loop:  \n\n- Input parsing under noisy, real-world data  \n- Planning correctness and robustness to adversarial inputs  \n- Tool invocation safety and idempotence  \n- Memory consistency and leakage risks  \n\n💡 **Practice:** Treat scenarios like integration tests: replay end-to-end flows and assert on both outcomes and side effects.\n\n### 5.2 Using DASF’s 35 agentic risks as test generators\n\nEach of DASF’s 35 agent-specific risks can seed red-team scenarios and simulation tests:[9]  \n\n- Prompt injection causing unauthorized tool calls  \n- Memory poisoning leading to misclassification  \n- Multi-agent collusion or cross-boundary confusion[9]  \n\nTeams can build a test matrix: risk ID → scenario → expected behavior → guardrail checks.\n\n### 5.3 SOC-specific replay testbeds\n\nSOC guides recommend replaying historical alerts and incidents to evaluate agents under realistic load and distribution.[3] Track:  \n\n- Precision\u002Frecall vs human triage  \n- Time-to-triage per alert  \n- False-positive amplification or suppression  \n- Latency overhead per event[3]  \n\n📊 **Tip:** Start in “shadow mode”: agents score and enrich alerts but do not affect live workflows until performance is validated.\n\n### 5.4 Guardrails from day one\n\nGuardrail frameworks (W&B Guardrails, NeMo Guardrails) are meant to be embedded early.[6] For a Foundry-style deployment:  \n\n- Define clear policies for unacceptable behaviors and tool calls  \n- Instrument all agent actions with logging and alerts  \n- Regularly review incidents to refine policies and update the spec  \n\n---\n\n## 6. Where Foundry fits next\n\nCisco’s Foundry specification can give enterprises a shared, open-source vocabulary for describing agent behavior, tool access, memory, and guardrails—independent of any single vendor stack.[1][2][9] Positioned alongside DASF, Daybreak, and AgentWorks, it helps shift the industry from opaque “clever bots” to documented, testable, and governable agentic systems.[4][7][9]  \n\nAs agentic AI moves deeper into SOCs, CI\u002FCD pipelines, and data platforms, the organizations that succeed will be those that treat their agents like critical infrastructure: specified, tested, monitored, and continuously hardened—not just prompted.[3][6][9]","\u003Cp>Agentic AI is moving from chat windows into pipelines that touch code, infrastructure, and production data. These systems can perceive, plan, act with tools, and learn from memory with limited human supervision, which fundamentally raises the blast radius of any failure or compromise.\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>Vendors are reacting:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fentities\u002F6a0d89e607a4fdbfcf5e8152-databricks\">Databricks\u003C\u002Fa> added Agentic AI as the 13th component in its AI Security Framework (DASF v3.0), with 35 new risks and 6 mitigation controls dedicated to agents.\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fentities\u002F6a0bb8b01f0b27c1f4270251-openai\">OpenAI\u003C\u002Fa>’s Daybreak and \u003Ca href=\"\u002Fentities\u002F69ea7cace1ca17caac372eab-crowdstrike\">CrowdStrike\u003C\u002Fa>’s AgentWorks both treat agents as first-class security subjects, not just UX layers on top of LLMs.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Cisco’s open-source Foundry specification is emerging as a potential common language for defining how agents are structured, governed, and defended. Foundry-style specifications can standardize how we describe agent capabilities, tool surfaces, memory behavior, and observability—much like DASF’s Agentic AI Extension standardizes risk taxonomy.\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>💡 \u003Cstrong>Orientation:\u003C\u002Fstrong> This article treats Foundry as a reference design. We position it among existing frameworks, infer core principles, walk through a reference architecture, and outline how to test and govern “Foundry-compliant” agent stacks in practice.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>1. The security problem: why agentic AI needs a formal specification\u003C\u002Fh2>\n\u003Cp>Agentic AI goes beyond classic prompt–response models. Instead of “answer this question,” we now have systems that:\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Decompose goals into sub-tasks\u003C\u002Fli>\n\u003Cli>Call external tools and APIs\u003C\u002Fli>\n\u003Cli>Coordinate with other agents\u003C\u002Fli>\n\u003Cli>Persist and update long-term memory\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>They operate autonomously across a perception → reasoning\u002Fplanning → action → learning loop using LLMs and other ML components.\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>⚠️ \u003Cstrong>Risk shift:\u003C\u002Fstrong> The concern moves from “Did the model hallucinate?” to “What can the agent \u003Cem>do\u003C\u002Fem> if it’s wrong—or if it’s compromised?”\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>Agentic AI in formal security frameworks\u003C\u002Fh3>\n\u003Cp>Databricks formalized this shift by extending DASF v3.0 with a dedicated Agentic AI component:\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>13th system component:\u003C\u002Fstrong> Agentic AI\u003C\u002Fli>\n\u003Cli>\u003Cstrong>35 new agent-specific risks:\u003C\u002Fstrong> memory, planning, tool use, and communication\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>6 new mitigation controls:\u003C\u002Fstrong> least privilege, sandboxing, human supervision, MCP hardening, and more\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This treats autonomy as a fundamentally new risk surface that needs its own control plane, not just optional checks on chatbots.\u003C\u002Fp>\n\u003Ch3>High-privilege \u003Ca href=\"\u002Fentities\u002F6a0be90a1f0b27c1f427162f-soc\">SOC\u003C\u002Fa> workflows already depend on agents\u003C\u002Fh3>\n\u003Cp>Security operations centers are wiring agents into SIEM and SOAR workflows.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa> Typical pattern:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Ingest SIEM alerts\u003C\u002Fli>\n\u003Cli>Enrich with asset, identity, and threat-intel data\u003C\u002Fli>\n\u003Cli>Propose classifications and next steps\u003C\u002Fli>\n\u003Cli>Trigger SOAR playbooks for low-risk actions\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>In one prototype, a triage agent silently downgraded noisy alerts. A parsing error on a rare alert type suppressed critical notifications from one \u003Ca href=\"\u002Fentities\u002F69ea7cace1ca17caac372eb2-edr\">EDR\u003C\u002Fa> source; only a human noticing fewer cases revealed the problem.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>➡️ \u003Cstrong>Lesson:\u003C\u002Fstrong> Silent, automated failures in high-privilege environments require a formal spec with built-in guardrails and monitoring.\u003C\u002Fp>\n\u003Ch3>Dedicated agentic security platforms and early-by-design moves\u003C\u002Fh3>\n\u003Cp>Security vendors are building agent-centric platforms:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002F2024_CrowdStrike-related_IT_outages\" class=\"wiki-link\" target=\"_blank\" rel=\"noopener\">CrowdStrike AgentWorks\u003C\u002Fa>\u003C\u002Fstrong> – lets SOC teams design, test, and deploy agents into \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FFalcon\" class=\"wiki-link\" target=\"_blank\" rel=\"noopener\">Falcon\u003C\u002Fa>, with governance, controls, and multi-model support (\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FClaude\" class=\"wiki-link\" target=\"_blank\" rel=\"noopener\">Claude\u003C\u002Fa>, GPT, \u003Ca href=\"\u002Fentities\u002F6a0a73ff1f0b27c1f426a60e-nemotron\">Nemotron\u003C\u002Fa>).\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>OpenAI Daybreak\u003C\u002Fstrong> – wraps GPT‑5.5 variants and \u003Ca href=\"\u002Fentities\u002F6a0b9b4f1f0b27c1f426f90a-codex-security\">Codex Security\u003C\u002Fa> into a stack that embeds security analysis into SDLC: code review, threat modeling, patch generation, sandbox testing.\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Daybreak’s stance: security must be built in from the first lines of code, not bolted on later.\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>💼 \u003Cstrong>Implication for Foundry:\u003C\u002Fstrong> Cisco’s open-source Foundry spec can be the vendor-neutral counterpart to these platforms: a shared schema for agent capabilities, tool wiring, permissions, and governance that any cloud, on-prem, or hybrid implementation can adopt.\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>2. Situating Cisco’s Foundry among agentic AI and security frameworks\u003C\u002Fh2>\n\u003Ch3>What “agentic AI” means for Foundry\u003C\u002Fh3>\n\u003Cp>In the Foundry context, “agentic AI” refers to autonomous systems that combine LLMs, other ML models, and external tools to complete complex tasks with minimal supervision.\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa> They:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Maintain internal state and memory\u003C\u002Fli>\n\u003Cli>Plan multi-step workflows\u003C\u002Fli>\n\u003Cli>Call APIs, databases, and runtimes\u003C\u002Fli>\n\u003Cli>Learn from past interactions\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This aligns with open-source views of agents as chaining perception, decision, and action rather than single-shot inferences.\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>Open-source agents vs proprietary platforms\u003C\u002Fh3>\n\u003Cp>Open-source stacks and specs (like Foundry) imply:\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Inspectable code\u002Fconfigs:\u003C\u002Fstrong> audit, extend, or fork flows as needed\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Deployment freedom:\u003C\u002Fstrong> on-prem, private cloud, hybrid; easier sovereignty\u002Fcompliance\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Governance responsibility:\u003C\u002Fstrong> you own permissions, logging, and incident response\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Trade-off: deep control and alignment with your infra, but you inherit operational burden and must enforce controls yourself.\u003C\u002Fp>\n\u003Cp>By contrast, AgentWorks and Daybreak provide managed environments with strong embedded guardrails but limited portability.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>Mapping Foundry to DASF’s Agentic AI Extension\u003C\u002Fh3>\n\u003Cp>Databricks’ Agentic AI Extension is a useful checklist for what any spec should cover:\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Risk catalog for planning, memory, tool use, multi-agent communication\u003C\u002Fli>\n\u003Cli>Controls: least privilege, sandboxing, human-in-the-loop review, MCP hardening\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>Guidance for mapping every agent, tool, and integration to these risks\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A Foundry spec can mirror this: define components, enumerate threats per component, and attach control families (authz, isolation, monitoring, fail-safes).\u003C\u002Fp>\n\u003Ch3>Foundry vs Daybreak and heterogeneous ecosystems\u003C\u002Fh3>\n\u003Cp>Daybreak is a vertically integrated, managed stack combining GPT‑5.5 and Codex Security for general, defensive, and offensive cyber workflows.\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa> Suitable for organizations that want one vendor to control models, tools, and sandboxing.\u003C\u002Fp>\n\u003Cp>Foundry targets portability: a blueprint that can run across clouds and stacks, including on-prem and hybrid scenarios like the OpenAI–Dell Codex partnership.\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa> That partnership emphasizes deploying “where the enterprise data already resides,” with sovereignty and residency as core design constraints.\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>Security vendors are also embedding agent design studios (AgentWorks) inside SOC platforms, with multi-model support and SOAR interoperability.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa> Any Foundry-style spec must therefore assume:\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Multiple LLM providers\u003C\u002Fli>\n\u003Cli>Mixed on-prem\u002Fcloud tools\u003C\u002Fli>\n\u003Cli>Cross-vendor trust and data boundaries\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>📊 \u003Cstrong>Mini-conclusion:\u003C\u002Fstrong> Against DASF, Daybreak, AgentWorks, and Codex-on-Dell, Foundry’s distinctive role is to define a vendor-neutral \u003Cem>schema\u003C\u002Fem> for secure agent behavior that can move across heterogeneous environments.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>3. Core principles likely defined in Cisco’s Foundry agentic AI security spec\u003C\u002Fh2>\n\u003Ch3>3.1 Formalizing the agent lifecycle\u003C\u002Fh3>\n\u003Cp>A mature spec should model the full lifecycle explicitly:\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Perception\u003C\u002Fstrong> – ingest text, events, logs, metrics\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reasoning \u002F planning\u003C\u002Fstrong> – decide on a course of action\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Action via tools\u003C\u002Fstrong> – call APIs, execute code, update systems\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Memory\u003C\u002Fstrong> – read\u002Fwrite long-term state\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Open-source guidance stresses that production agents must make these phases inspectable and auditable, not hide them inside opaque prompts.\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>⚡ \u003Cstrong>Spec expectation:\u003C\u002Fstrong> Foundry should require explicit interfaces, policies, and logs for each phase, rather than “magic” inside a single LLM call.\u003C\u002Fp>\n\u003Ch3>3.2 Tool and memory risks as first-class citizens\u003C\u002Fh3>\n\u003Cp>DASF’s Agentic AI Extension treats tool ecosystems and MCP-based integrations as major attack surfaces.\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa> Risks include:\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Prompt injection leading to dangerous API calls\u003C\u002Fli>\n\u003Cli>Escalation via overly broad tool scopes\u003C\u002Fli>\n\u003Cli>Cross-tenant or cross-environment data exfiltration\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A Foundry spec should therefore:\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Define per-tool scopes and least-privilege defaults\u003C\u002Fli>\n\u003Cli>Mandate sandboxing for high-risk tools (code execution, infra changes)\u003C\u002Fli>\n\u003Cli>Set policies for memory retention, redaction, and access control\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>3.3 SOC-embedded agent principles\u003C\u002Fh3>\n\u003Cp>For SOC use cases (SIEM triage, enrichment, SOAR orchestration), the spec should define \u003Cstrong>tiers of authority\u003C\u002Fstrong>:\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Read-only analysis:\u003C\u002Fstrong> log\u002Fasset queries, scoring, explanations\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Low-risk automation:\u003C\u002Fstrong> ticket enrichment, tagging, suggested playbooks\u003C\u002Fli>\n\u003Cli>\u003Cstrong>High-impact response:\u003C\u002Fstrong> firewall changes, account lockdowns, EDR actions\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Some SOCs already prohibit agents from closing incidents or performing containment without explicit, logged human approval—even at high confidence—to prevent large-scale, wrongheaded actions.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>3.4 Security-by-design in development workflows\u003C\u002Fh3>\n\u003Cp>Daybreak’s Codex Security analyzes codebases, builds editable threat models, and tests patches in sandboxed environments before recommending merges.\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa> A Foundry-aligned spec should:\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Treat code and infra analysis as standard agent patterns\u003C\u002Fli>\n\u003Cli>Require sandboxed test environments for any code-modifying agent\u003C\u002Fli>\n\u003Cli>Encourage machine-readable evidence (test logs, exploit traces) for audits\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>3.5 Guardrails, ethics, and limitations\u003C\u002Fh3>\n\u003Cp>Guardrail frameworks (Weights & Biases Guardrails, NVIDIA NeMo Guardrails, \u003Ca href=\"http:\u002F\u002Fnexos.ai\">nexos.ai\u003C\u002Fa>, and others) enforce behavioral constraints, detect PII leakage, moderate tool calls, and manage compliance.\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>A Foundry spec should codify:\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Mandatory risk assessment and monitoring hooks\u003C\u002Fli>\n\u003Cli>Policy-based blocking of specific tool calls or data flows\u003C\u002Fli>\n\u003Cli>Documentation of model biases and limitations, especially in SOC contexts\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>💡 \u003Cstrong>Mini-conclusion:\u003C\u002Fstrong> Across these principles, agents are treated like critical software components—with explicit lifecycle, threat models, and guardrails—not “smart prompts.”\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>4. Reference architecture: implementing a Foundry-compliant secure agent stack\u003C\u002Fh2>\n\u003Ch3>4.1 Layered architecture\u003C\u002Fh3>\n\u003Cp>A practical mental model:\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>LLM\u002FModel layer\u003C\u002Fstrong> – GPT, Claude, Nemotron, open-source LLMs\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Agent core\u003C\u002Fstrong> – planner, memory manager, tool orchestrator\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Security substrate (Foundry layer)\u003C\u002Fstrong> – policies, authorization, logging, guardrails\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Integration layer\u003C\u002Fstrong> – SIEM, SOAR, ticketing, CI\u002FCD, data platforms\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>CrowdStrike’s AgentWorks already shows pluggable model layers under a common governance umbrella; Foundry should formalize this separation so LLMs can be swapped without redoing security controls.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>4.2 Control plane and governance APIs\u003C\u002Fh3>\n\u003Cp>For an open-source agent stack, the control plane should expose:\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Policy definitions per agent and tool\u003C\u002Fli>\n\u003Cli>Audit logs for every tool call and memory write\u003C\u002Fli>\n\u003Cli>Versioning for prompts, workflows, and policies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Example YAML-style Foundry policy:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">agent: soc-triage\npermissions:\n  tools:\n    - name: query_siem\n      scope: read_only\n      max_rows: 5000\n    - name: trigger_soar_playbook\n      scope: restricted\n      require_human_approval: true\nmemory:\n  retention_days: 30\n  pii_redaction: enabled\nguardrails:\n  provider: nemo\n  blocks:\n    - data_exfiltration\n    - prompt_injection\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>This is the level of explicitness a spec should encourage for secure operations.\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>4.3 On‑prem and hybrid patterns\u003C\u002Fh3>\n\u003Cp>The OpenAI–Dell Codex integration illustrates how agents can run close to enterprise data on Dell AI Data Platform and Dell AI Factory, keeping inference and context within the customer perimeter.\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa> Foundry-aligned deployments can:\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Self-host the agent runtime in a data center or VPC\u003C\u002Fli>\n\u003Cli>Connect to local data platforms and observability stacks\u003C\u002Fli>\n\u003Cli>Route only minimal signals to external LLM APIs under strict policies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>📊 \u003Cstrong>Compliance angle:\u003C\u002Fstrong> This topology directly supports sovereignty and residency requirements common in European and regulated sectors.\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-5\" class=\"citation-link\" title=\"View source [5]\">[5]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>4.4 SOC-centric deployment example\u003C\u002Fh3>\n\u003Cp>A Foundry-compliant SOC agent stack might:\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Ingest SIEM alerts via streaming\u003C\u002Fli>\n\u003Cli>Enrich alerts with CMDB, IAM, and threat-intel data\u003C\u002Fli>\n\u003Cli>Apply guardrails to prevent direct destructive actions\u003C\u002Fli>\n\u003Cli>Surface suggested triage decisions in the analyst console\u003C\u002Fli>\n\u003Cli>Trigger only low-risk SOAR tasks (tagging, ticket creation) automatically\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>SOC agent guides emphasize including architecture diagrams, performance metrics, and operational guardrails—elements a Foundry spec should require in deployment documentation.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>4.5 DevSecOps workflow with sandboxed agents\u003C\u002Fh3>\n\u003Cp>Inspired by Daybreak, a secure development workflow can:\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa>\u003C\u002Fp>\n\u003Col>\n\u003Cli>Scan codebases and build an editable threat model\u003C\u002Fli>\n\u003Cli>Identify realistic attack paths and risky dependencies\u003C\u002Fli>\n\u003Cli>Propose code\u002Fconfig changes\u003C\u002Fli>\n\u003Cli>Test changes in a sandbox that attempts known exploits\u003C\u002Fli>\n\u003Cli>Export evidence and results for human review before merges\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>⚠️ \u003Cstrong>Non-negotiable:\u003C\u002Fstrong> Agents never write directly to production; changes flow through CI\u002FCD with standard approvals.\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-8\" class=\"citation-link\" title=\"View source [8]\">[8]\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch3>4.6 Guardrail layer integration\u003C\u002Fh3>\n\u003Cp>Guardrail products (W&B Guardrails, NeMo Guardrails, \u003Ca href=\"http:\u002F\u002Fnexos.ai\">nexos.ai\u003C\u002Fa>) can act as a pre-execution filter for prompts, tool outputs, and planned actions.\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>Example orchestration:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-python\">plan = agent.plan(observation)\nvalidated_plan = guardrails.validate(plan)\nif not validated_plan.approved:\n    log_and_alert(validated_plan.issues)\nelse:\n    agent.execute(validated_plan)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>This pattern helps catch risky tool invocations before they hit critical systems.\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>5. Testing, guardrails, and evaluation for Foundry-style agentic AI\u003C\u002Fh2>\n\u003Ch3>5.1 Testing the full perception–reason–act loop\u003C\u002Fh3>\n\u003Cp>Open-source reliability work stresses that single-prompt unit tests are insufficient.\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa> You must test the complete loop:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Input parsing under noisy, real-world data\u003C\u002Fli>\n\u003Cli>Planning correctness and robustness to adversarial inputs\u003C\u002Fli>\n\u003Cli>Tool invocation safety and idempotence\u003C\u002Fli>\n\u003Cli>Memory consistency and leakage risks\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>💡 \u003Cstrong>Practice:\u003C\u002Fstrong> Treat scenarios like integration tests: replay end-to-end flows and assert on both outcomes and side effects.\u003C\u002Fp>\n\u003Ch3>5.2 Using DASF’s 35 agentic risks as test generators\u003C\u002Fh3>\n\u003Cp>Each of DASF’s 35 agent-specific risks can seed red-team scenarios and simulation tests:\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Prompt injection causing unauthorized tool calls\u003C\u002Fli>\n\u003Cli>Memory poisoning leading to misclassification\u003C\u002Fli>\n\u003Cli>Multi-agent collusion or cross-boundary confusion\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Teams can build a test matrix: risk ID → scenario → expected behavior → guardrail checks.\u003C\u002Fp>\n\u003Ch3>5.3 SOC-specific replay testbeds\u003C\u002Fh3>\n\u003Cp>SOC guides recommend replaying historical alerts and incidents to evaluate agents under realistic load and distribution.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa> Track:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Precision\u002Frecall vs human triage\u003C\u002Fli>\n\u003Cli>Time-to-triage per alert\u003C\u002Fli>\n\u003Cli>False-positive amplification or suppression\u003C\u002Fli>\n\u003Cli>Latency overhead per event\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>📊 \u003Cstrong>Tip:\u003C\u002Fstrong> Start in “shadow mode”: agents score and enrich alerts but do not affect live workflows until performance is validated.\u003C\u002Fp>\n\u003Ch3>5.4 Guardrails from day one\u003C\u002Fh3>\n\u003Cp>Guardrail frameworks (W&B Guardrails, NeMo Guardrails) are meant to be embedded early.\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa> For a Foundry-style deployment:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Define clear policies for unacceptable behaviors and tool calls\u003C\u002Fli>\n\u003Cli>Instrument all agent actions with logging and alerts\u003C\u002Fli>\n\u003Cli>Regularly review incidents to refine policies and update the spec\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2>6. Where Foundry fits next\u003C\u002Fh2>\n\u003Cp>Cisco’s Foundry specification can give enterprises a shared, open-source vocabulary for describing agent behavior, tool access, memory, and guardrails—independent of any single vendor stack.\u003Ca href=\"#source-1\" class=\"citation-link\" title=\"View source [1]\">[1]\u003C\u002Fa>\u003Ca href=\"#source-2\" class=\"citation-link\" title=\"View source [2]\">[2]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa> Positioned alongside DASF, Daybreak, and AgentWorks, it helps shift the industry from opaque “clever bots” to documented, testable, and governable agentic systems.\u003Ca href=\"#source-4\" class=\"citation-link\" title=\"View source [4]\">[4]\u003C\u002Fa>\u003Ca href=\"#source-7\" class=\"citation-link\" title=\"View source [7]\">[7]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>As agentic AI moves deeper into SOCs, CI\u002FCD pipelines, and data platforms, the organizations that succeed will be those that treat their agents like critical infrastructure: specified, tested, monitored, and continuously hardened—not just prompted.\u003Ca href=\"#source-3\" class=\"citation-link\" title=\"View source [3]\">[3]\u003C\u002Fa>\u003Ca href=\"#source-6\" class=\"citation-link\" title=\"View source [6]\">[6]\u003C\u002Fa>\u003Ca href=\"#source-9\" class=\"citation-link\" title=\"View source [9]\">[9]\u003C\u002Fa>\u003C\u002Fp>\n","Agentic AI is moving from chat windows into pipelines that touch code, infrastructure, and production data. These systems can perceive, plan, act with tools, and learn from memory with limited human s...","hallucinations",[],2119,11,"2026-05-20T22:45:45.516Z",[17,22,26,30,34,38,42,46,50],{"title":18,"url":19,"summary":20,"type":21},"Qu'est-ce que l'Agentic AI ?","https:\u002F\u002Fwww.trendmicro.com\u002Ffr_fr\u002Fwhat-is\u002Fai\u002Fagentic-ai.html","Qu'est-ce que l'Agentic AI ? par Fernando Cardoso\nDernière mise à jour Mar 27, 2026\n\nL’IA agentique est une forme avancée d’intelligence artificielle (IA) qui utilise des « agents » d’IA autonomes pou...","kb",{"title":23,"url":24,"summary":25,"type":21},"Fiabiliser un agent d'IA open source : tests et garde-fous - Incremys","https:\u002F\u002Fwww.incremys.com\u002Fressources\u002Fblog\u002Fagent-ia-open-source","Fiabiliser un agent d'IA open source : tests et garde-fous - Incremys\n\nAtelier Tech for Retail 2025 : Du SEO au GEO - gagner en visibilité à l’ère des moteurs génératifs\n\nBack to blog\n\nComparer agent ...",{"title":27,"url":28,"summary":29,"type":21},"Agents IA pour le SOC : Triage Automatisé des Alertes","https:\u002F\u002Fayinedjimi-consultants.fr\u002Farticles\u002Fia-agents-soc-triage-alertes","Agents IA pour le SOC : Triage Automatisé des Alertes\n\n13 février 2026\n\nMis à jour le 19 mai 2026\n\n17 min de lecture\n\n5348 mots\n\nVues: 716\n\nTélécharger le PDF\n\nGuide complet sur les agents IA pour le ...",{"title":31,"url":32,"summary":33,"type":21},"Une plateforme pour concevoir, tester et déployer des agents IA dans Falcon","https:\u002F\u002Fwww.linformaticien.com\u002Fmagazine\u002Fcybersecurite\u002F64660-une-plateforme-pour-concevoir-tester-et-deployer-des-agents-ia-dans-falcon.html","CrowdStrike a annoncé le lancement de son écosystème AI AgentWorks, une plateforme no-code qui permet aux équipes de sécurité de concevoir, tester et déployer des agents d’intelligence artificielle da...",{"title":35,"url":36,"summary":37,"type":21},"OpenAI et Dell rapprochent Codex des données d’entreprise sur site et en environnement hybride - IT SOCIAL","https:\u002F\u002Fitsocial.fr\u002Fcloud-infrastructure-it\u002Fcloud-infrastructure-it-actualites\u002Fopenai-et-dell-rapprochent-codex-des-donnees-dentreprise-sur-site-et-en-environnement-hybride\u002F","OpenAI et Dell ouvrent le déploiement de Codex aux environnements hybrides et sur site. L'intégration vise la plateforme Dell AI Data Platform et la pile Dell AI Factory, avec pour objectif de rapproc...",{"title":39,"url":40,"summary":41,"type":21},"Les 5 principaux garde-fous de l'IA: Poids et biais & NVIDIA NeMo","https:\u002F\u002Faimultiple.com\u002Ffr\u002Fai-guardrails","Les garde-fous de l'IA comblent les lacunes liées à l'absence de contrôles d'accès et à la gestion des déploiements d'IA, en définissant des limites à l'utilisation de l'IA, en soutenant la conformité...",{"title":43,"url":44,"summary":45,"type":21},"OpenAI dégaine Daybreak : sa plateforme cybersécurité pour concurrencer Anthropic","https:\u002F\u002Fwww.it-connect.fr\u002Fopenai-degaine-daybreak-sa-plateforme-cybersecurite-pour-concurrencer-anthropic\u002F","OpenAI vient de lancer Daybreak, une plateforme de cybersécurité s'appuyant sur ses modèles GPT-5.5 et son agent Codex Security. L'objectif : rivaliser avec Anthropic dans la chasse aux vulnérabilités...",{"title":47,"url":48,"summary":49,"type":21},"Cybersécurité : qu’est-ce que Daybreak, la nouvelle initiative d’OpenAI ?","https:\u002F\u002Fwww.blogdumoderateur.com\u002Fcybersecurite-daybreak-nouvelle-initiative-openai\u002F","Daybreak est une initiative d’OpenAI lancée le 11 mai, axée sur la cybersécurité et la défense, qui regroupe ses modèles IA spécialisés, son agent Codex Security et un écosystème de partenaires de séc...",{"title":51,"url":52,"summary":53,"type":21},"Sécurité de l'IA agentique : Nouveaux risques et contrôles dans le cadre de sécurité de l'IA Databricks (DASF v3.0) | Databricks Blog","https:\u002F\u002Fwww.databricks.com\u002Ffr\u002Fblog\u002Fagentic-ai-security-new-risks-and-controls-databricks-ai-security-framework-dasf-v30","Sécurité de l'IA agentique : Nouveaux risques et contrôles dans le cadre de sécurité de l'IA Databricks (DASF v3.0)\n\nRésumé\n\nLe Databricks AI Security Framework (DASF) couvre désormais l'IA Agentic co...",{"totalSources":55},9,{"generationDuration":57,"kbQueriesCount":55,"confidenceScore":58,"sourcesCount":55},219808,100,{"metaTitle":60,"metaDescription":61},"Agentic AI Security: Cisco Foundry for Standardized Defenses","Worried about agent-driven breaches? Explore Cisco Foundry's open specification to standardize agent structure, governance, and defenses—read to get a practical","en","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1484557052118-f32bd25b45b5?ixid=M3w4OTczNDl8MHwxfHNlYXJjaHwxfHxkZXNpZ25pbmclMjBzZWN1cmUlMjBhZ2VudGljJTIwY2lzY298ZW58MXwwfHx8MTc3OTMzNDE0Mnww&ixlib=rb-4.1.0&w=1200&h=630&fit=crop&crop=entropy&auto=format,compress&q=60",{"photographerName":65,"photographerUrl":66,"unsplashUrl":67},"Kvistholt Photography","https:\u002F\u002Funsplash.com\u002F@freeche?utm_source=coreprose&utm_medium=referral","https:\u002F\u002Funsplash.com\u002Fphotos\u002Fphoto-of-computer-cables-oZPwn40zCK4?utm_source=coreprose&utm_medium=referral",false,null,{"key":71,"name":72,"nameEn":72},"ai-engineering","AI Engineering & LLM Ops",[74,76,78,80],{"text":75},"Cisco’s Foundry specification provides a vendor-neutral schema that standardizes agent components, tool scopes, memory policies, and observability for heterogeneous on‑prem, cloud, and hybrid deployments.",{"text":77},"Databricks’ DASF v3.0 added Agentic AI as the 13th system component with 35 agent-specific risks and 6 mitigation controls, and Foundry can map those risks to concrete policy and control surfaces.",{"text":79},"A Foundry‑compliant stack must expose per-agent policy APIs, audit logs for every tool call and memory write, and versioned YAML-style policies to enforce least privilege and sandboxing at scale.",{"text":81},"SOC deployments must tier agent authority (read-only, low-risk automation, high-impact response) and require human approval for high-impact actions to prevent silent, automated failures.",[83,86,89],{"question":84,"answer":85},"What is the core purpose of Cisco’s Foundry specification?","Foundry’s core purpose is to define a vendor-neutral, machine-readable schema that makes agentic AIs auditable, governable, and portable across environments. It codifies agent lifecycle phases (perception, planning, action, memory), tool interfaces, memory retention and redaction policies, and observability hooks so enterprises can enforce least‑privilege, sandboxing, and monitoring consistently. By standardizing policy and control primitives (permissions, guardrails, audit logs, versioning), Foundry enables security teams to map known risk catalogs—such as DASF’s 35 agent risks—into actionable controls and automated enforcement across heterogeneous LLMs and toolchains.",{"question":87,"answer":88},"How does Foundry complement existing frameworks like DASF, Daybreak, and AgentWorks?","Foundry complements other frameworks by serving as the implementation‑oriented specification that maps taxonomy and controls into operational artifacts. DASF provides a risk catalog and high‑level controls (35 risks, 6 mitigations); Foundry translates those into per-agent policy schemas, guardrail integrations, audit requirements, and deployment topologies. Unlike proprietary stacks (Daybreak, AgentWorks) that bundle models and guardrails, Foundry is vendor-neutral and portable, enabling the same security posture to be applied on‑prem, hybrid, or multi‑cloud environments while preserving sovereignty and allowing organizations to integrate managed or self-hosted model layers.",{"question":90,"answer":91},"What practical controls and tests should organizations require for Foundry‑compliant agents?","Organizations must require explicit per-tool scoping, least‑privilege defaults, mandatory sandboxing for code or infra actions, human‑approval gates for high‑impact tasks, and comprehensive audit logs for every tool call and memory write. Testing must cover end‑to‑end perception→plan→act loops, replay real SOC incident streams in shadow mode, and use DASF‑derived red‑team scenarios (prompt injection, memory poisoning, tool escalation). Additionally, include CI\u002FCD sandbox tests for code‑modifying agents, automated guardrail validation pre‑execution, and periodic policy reviews driven by incident telemetry to continuously harden agent behavior.",[93,100,106,112,119,124,130,135,140,147,152,158,163,168],{"id":94,"name":95,"type":96,"confidence":97,"wikipediaUrl":69,"slug":98,"mentionCount":99},"69ea7cade1ca17caac372eb6","SIEM","concept",0.95,"69ea7cade1ca17caac372eb6-siem",8,{"id":101,"name":102,"type":96,"confidence":97,"wikipediaUrl":103,"slug":104,"mentionCount":105},"6a0be90a1f0b27c1f427162f","SOC","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSOC","6a0be90a1f0b27c1f427162f-soc",7,{"id":107,"name":108,"type":96,"confidence":109,"wikipediaUrl":69,"slug":110,"mentionCount":111},"6a0e39b007a4fdbfcf5ea778","Agentic AI",0.98,"6a0e39b007a4fdbfcf5ea778-agentic-ai",6,{"id":113,"name":114,"type":96,"confidence":115,"wikipediaUrl":116,"slug":117,"mentionCount":118},"69ea7cace1ca17caac372eb2","EDR",0.94,"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEDR","69ea7cace1ca17caac372eb2-edr",5,{"id":120,"name":121,"type":96,"confidence":115,"wikipediaUrl":69,"slug":122,"mentionCount":123},"6a0e39b007a4fdbfcf5ea779","DASF v3.0","6a0e39b007a4fdbfcf5ea779-dasf-v3-0",3,{"id":125,"name":126,"type":96,"confidence":127,"wikipediaUrl":69,"slug":128,"mentionCount":129},"6a0e39b007a4fdbfcf5ea77a","Cisco Foundry",0.96,"6a0e39b007a4fdbfcf5ea77a-cisco-foundry",1,{"id":131,"name":132,"type":96,"confidence":133,"wikipediaUrl":69,"slug":134,"mentionCount":129},"6a0e39b307a4fdbfcf5ea77f","Sandboxing",0.92,"6a0e39b307a4fdbfcf5ea77f-sandboxing",{"id":136,"name":137,"type":96,"confidence":133,"wikipediaUrl":138,"slug":139,"mentionCount":129},"6a0e39b207a4fdbfcf5ea77e","Least privilege","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPrinciple_of_least_privilege","6a0e39b207a4fdbfcf5ea77e-least-privilege",{"id":141,"name":142,"type":143,"confidence":144,"wikipediaUrl":145,"slug":146,"mentionCount":105},"6a0bb8b01f0b27c1f4270251","OpenAI","organization",0.99,"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOpenAI","6a0bb8b01f0b27c1f4270251-openai",{"id":148,"name":149,"type":143,"confidence":109,"wikipediaUrl":150,"slug":151,"mentionCount":111},"6a0d89e607a4fdbfcf5e8152","Databricks","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDatabricks","6a0d89e607a4fdbfcf5e8152-databricks",{"id":153,"name":154,"type":143,"confidence":109,"wikipediaUrl":155,"slug":156,"mentionCount":157},"69ea7cace1ca17caac372eab","CrowdStrike","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FCrowdStrike","69ea7cace1ca17caac372eab-crowdstrike",4,{"id":159,"name":160,"type":161,"confidence":97,"wikipediaUrl":69,"slug":162,"mentionCount":157},"6a0e331c07a4fdbfcf5ea66a","SOAR","other","6a0e331c07a4fdbfcf5ea66a-soar",{"id":164,"name":165,"type":161,"confidence":166,"wikipediaUrl":69,"slug":167,"mentionCount":129},"6a0e39b207a4fdbfcf5ea77d","OpenAI–Dell Codex partnership",0.86,"6a0e39b207a4fdbfcf5ea77d-openai-dell-codex-partnership",{"id":169,"name":170,"type":171,"confidence":115,"wikipediaUrl":172,"slug":173,"mentionCount":157},"6a0b9b4f1f0b27c1f426f90a","Codex Security","product","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FCodex_(AI_agent)","6a0b9b4f1f0b27c1f426f90a-codex-security",[175,182,190,197],{"id":176,"title":177,"slug":178,"excerpt":179,"category":11,"featuredImage":180,"publishedAt":181},"6a0eb023a83199a61232a96a","AI-Enabled Cyber Attacks Up 89%: Inside the 9 Autonomous Breaches Reshaping Security in 2026","ai-enabled-cyber-attacks-up-89-inside-the-9-autonomous-breaches-reshaping-security-in-2026","From Assisted to Autonomous: Why AI Cyber Attacks Spiked 89% in 2026  \n\nFor years, “AI in cybercrime” meant:  \n\n- Better phishing content  \n- Faster malware generation  \n- Scaled personalization and f...","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1775994121064-e75fa6f3e84c?ixid=M3w4OTczNDl8MHwxfHNlYXJjaHwxfHxlbmFibGVkJTIwY3liZXIlMjBhdHRhY2tzJTIwaW5zaWRlfGVufDF8MHx8fDE3NzkzNTU3MzJ8MA&ixlib=rb-4.1.0&w=1200&h=630&fit=crop&crop=entropy&auto=format,compress&q=60","2026-05-21T07:18:38.344Z",{"id":183,"title":184,"slug":185,"excerpt":186,"category":187,"featuredImage":188,"publishedAt":189},"6a0e937fa83199a61232a86a","Microsoft RAMPART and Clarity: A Practical Blueprint for Securing AI Agents in Production","microsoft-rampart-and-clarity-a-practical-blueprint-for-securing-ai-agents-in-production","Autonomous AI agents now sit in workflows that can provision credentials, rotate keys, export audit logs, and apply Terraform plans from a single prompt. [3] They amplify existing risks—overshared doc...","safety","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1662947036644-ecfde1221ac7?ixid=M3w4OTczNDl8MHwxfHNlYXJjaHwxfHxtaWNyb3NvZnQlMjByYW1wYXJ0fGVufDF8MHx8fDE3NzkzNDAzOTd8MA&ixlib=rb-4.1.0&w=1200&h=630&fit=crop&crop=entropy&auto=format,compress&q=60","2026-05-21T05:13:16.940Z",{"id":191,"title":192,"slug":193,"excerpt":194,"category":11,"featuredImage":195,"publishedAt":196},"6a0e8469a83199a612329a7a","Agentic AI in the Kill Chain: How Autonomous Agents Expand Your Attack Surface and Enable Lateral Movement","agentic-ai-in-the-kill-chain-how-autonomous-agents-expand-your-attack-surface-and-enable-lateral-movement","Agentic AI has moved from answering questions to operating: planning, calling tools, manipulating data, and chaining actions across your stack.[1][9]  \n\nThat makes every connected API, datastore, SaaS...","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1652191337993-e4bcdd3bbc08?ixid=M3w4OTczNDl8MHwxfHNlYXJjaHwxfHxhZ2VudGljJTIwa2lsbCUyMGNoYWluJTIwYXV0b25vbW91c3xlbnwxfDB8fHwxNzc5MzU1NzM0fDA&ixlib=rb-4.1.0&w=1200&h=630&fit=crop&crop=entropy&auto=format,compress&q=60","2026-05-21T04:10:32.575Z",{"id":198,"title":199,"slug":200,"excerpt":201,"category":11,"featuredImage":202,"publishedAt":203},"6a0e3d26a83199a6123245b1","Agentic AI Security: How Autonomous Agents Expand the Attack Surface and Enable Lateral Movement","agentic-ai-security-how-autonomous-agents-expand-the-attack-surface-and-enable-lateral-movement","Agentic AI turns large language models (LLMs) from conversational copilots into autonomous operators wired into APIs, cloud consoles, and internal tools. The threat model shifts from “untrusted text i...","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1740301982969-bea22f0d02e1?ixid=M3w4OTczNDl8MHwxfHNlYXJjaHwxfHxhZ2VudGljJTIwc2VjdXJpdHklMjBhdXRvbm9tb3VzJTIwYWdlbnRzfGVufDF8MHx8fDE3NzkzMzQxMzR8MA&ixlib=rb-4.1.0&w=1200&h=630&fit=crop&crop=entropy&auto=format,compress&q=60","2026-05-20T23:08:31.124Z",["Island",205],{"key":206,"params":207,"result":209},"ArticleBody_AucpSDe09vUlvBLmeSuXuJXMASuP6vmJfKooiRyg0",{"props":208},"{\"articleId\":\"6a0e384aa83199a612324341\",\"linkColor\":\"red\"}",{"head":210},{}]