Agentic AI Security Best Practices Guide - Initial Draft - #9
Open
flucktemberg-sap wants to merge 1 commit into
Open
Agentic AI Security Best Practices Guide - Initial Draft#9flucktemberg-sap wants to merge 1 commit into
flucktemberg-sap wants to merge 1 commit into
Conversation
Deliverable Covers secrets management, MCP/tool invocation security, HITL guardrails, eval frameworks, and post-incident forensics. Each section pairs a production failure pattern with an architectural control and decision framework. Includes a curated reference table and source ledger.
|
thanks for creating this fernando! Solid comprehensive draft. I like the failure-pattern → control → decision-framework structure. I had a question: |
adigidh
reviewed
Jul 24, 2026
| |---|---|---| | ||
| | Static API key (no control, baseline) | Days to months, until manually revoked | Full scope of key's permissions, indefinitely | | ||
| | Dynamic secrets (Vault) | 15–60 minutes, configurable | Single resource type, single operation | | ||
| | Workload identity | 1 hour (cloud default, configurable lower) | IAM role scope; bounded by role design | |
There was a problem hiding this comment.
The decision table comparing blast radius across credential patterns is nice.
I'm curious, for the workload identity row, is there guidance planned for multi-cloud or hybrid scenarios where an agent might need to assume roles across cloud boundaries?
adigidh
reviewed
Jul 24, 2026
| | Static API key (no control, baseline) | Days to months, until manually revoked | Full scope of key's permissions, indefinitely | | ||
| | Dynamic secrets (Vault) | 15–60 minutes, configurable | Single resource type, single operation | | ||
| | Workload identity | 1 hour (cloud default, configurable lower) | IAM role scope; bounded by role design | | ||
| | Confidential computing | Not applicable (hardware-protected) | Bounded by enclave; inaccessible to hypervisor | |
There was a problem hiding this comment.
for the confidential computing entry, do you anticipate adding a note about the performance and operational overhead tradeoffs?
adigidh
reviewed
Jul 24, 2026
|
|
||
| Maturity: GA (production-ready), Beta (publicly released with caveats), Experimental. Cost: Free, Moderate ($100–$2,000/mo at team scale), Enterprise. Status reflects early 2026; re-verify before procurement. | ||
|
|
||
| | Area | Tool | Type | Maturity | Cost | Notes | |
There was a problem hiding this comment.
Really useful table. One question: several tools are listed as "Free" but are cloud-hosted services (e.g., Cloudflare MCP Portals). Is 'Free' referring to the current free tier, or to the open-source or the self-hostable version?
jamesward
reviewed
Aug 3, 2026
| **The control.** OAuth secures the *connection*; it does not secure the *content* of what a verified server sends. Both layers are required: | ||
|
|
||
| - **Pre-deployment evaluation, every server, no exceptions:** confirm the source repository exists and has been active within 90 days; cross-reference against the Vulnerable MCP Project tracker; run a static scanner (Cisco MCP Scanner as the minimum viable check; Invariant Labs mcp-scan as a runtime complement) before any production connection. | ||
| - **Transport requirements:** treat third-party stdio servers as equivalent to running an arbitrary local binary, full user privilege, no cryptographic provenance. For HTTP transport, require OAuth 2.1 with PKCE and token audience binding (RFC 8707) regardless of what the spec marks as optional. |
There was a problem hiding this comment.
There are three remote MCP use cases we should cover:
- End users auth direct to MCP
- Agents pass their own auth through to the MCP (in custom agents that share an IDP with the backing MCP servers)
- Other machine to machine auth where user identity isn't needed
mindpower
reviewed
Aug 4, 2026
|
|
||
| **The failure pattern.** Cisco's scan of 31,132 marketplace skills found 26.1% contained at least one vulnerability; supply-chain characteristics co-occurred with data-exfiltration patterns in 81% of confirmed malicious skills. Snyk's ToxicSkills study found 10.9% of scanned skills exposed secrets or hardcoded credentials outright. The Cato CTRL proof-of-concept showed how low the bar is: a single inserted function call in an otherwise-legitimate, open-source skill delivered ransomware, with the skill's stated purpose and description unchanged. The deeper structural problem is the **consent gap**: approving a skill's first execution can authorize a scope of action broader than what was previewed, and that approval persists as a standing grant , not a one-time decision , until explicitly revoked. | ||
|
|
||
| **The control: a three-tier verification model.** |
Member
There was a problem hiding this comment.
I saw we only covers skills here. Should we also consider Agents (like A2A), MCP, etc?
|
|
||
| **The control: seven event categories**, most deployments today capture roughly three of them: | ||
|
|
||
| 1. **Action events** - every tool invocation/API call/database write, with tool ID, parameters, response, agent identity, and the credential active at execution time. The credential field is where most implementations fail; without per-agent identity (Section 2), delegation-chain reconstruction is not incomplete, it is structurally impossible. |
Member
There was a problem hiding this comment.
These are also closely related to observability and traceability WG. I believe we also need some type of global invocation id (global immutable agent/tool/caller identifier, etc) so we can reconstruct the whole agentic call trace for the analysis.
MatthewKhouzam
suggested changes
Aug 10, 2026
MatthewKhouzam
left a comment
MatthewKhouzam
left a comment
There was a problem hiding this comment.
please rename the file. no version numbers inthe file name
sicoyle
reviewed
Aug 10, 2026
sicoyle
left a comment
sicoyle
left a comment
There was a problem hiding this comment.
almost done, but thank you for putting this together and giving us a phenomenal starting point - you rock!! 🙌 👏
I will finish my review after our current WG meeting :)
| Working Group: Security & Privacy (AAIF) | ||
| Deliverable: 4 of 5 - Agentic AI Security Best Practices Guide | ||
| Status: Draft v0.1, for WG review | ||
| Co-Leads: Fernando Lucktemberg (and co-lead, TBD) |
Comment on lines
+12
to
+14
| This guide consolidates practical, implementable guidance for builders deploying agentic AI systems, organized around five areas: secrets management, secure tool invocation, guardrails, eval frameworks, and post-incident forensics. It closes with a curated reference section pointing to recommended external frameworks, standards, and tooling. | ||
|
|
||
| **Explicitly out of scope:** agent identity and delegated authorization architecture (SPIFFE/SVID workload attestation, RFC 8693 delegation-chain encoding, UCAN capability tokens, and the broader agent-to-agent trust model). That work is contributed to the Identity and Trust WG and surfaced to this WG's audience through the Cross-WG Security and Privacy Review Checklist (Deliverable 5), not duplicated here. Where secrets-management patterns below touch credential exchange mechanics, they are scoped narrowly to credential elimination, not to the identity/authorization layer built on top of it. |
There was a problem hiding this comment.
it would be really nice to spell out what the various acronyms in this md file are pls 🙏
|
|
||
| ## 2. Secrets Management | ||
|
|
||
| **The failure pattern.** Static, long-lived credentials , API keys, shared service-account passwords, environment-variable-injected secrets , are structurally incompatible with agentic deployment. Every credential an agent carries is a durable attack surface: loggable, serializable, leakable to version control, and extractable through prompt injection without requiring a zero-day. Obsidian Security's 2025 AI Agent Security Report found 90% of deployed agents hold roughly ten times more privilege than any single task requires. The blast radius of a compromised static credential is not bounded by its intended scope; it is bounded only by an attacker's lateral-movement capability. CVE-2025-68664 ("LangGrinch," CVSS 9.3) demonstrated the mechanism directly: a crafted prompt triggers unsafe deserialization of an agent framework's internal state, and the serialized output contains whatever credentials were sitting in the environment. |
There was a problem hiding this comment.
Suggested change
| **The failure pattern.** Static, long-lived credentials , API keys, shared service-account passwords, environment-variable-injected secrets , are structurally incompatible with agentic deployment. Every credential an agent carries is a durable attack surface: loggable, serializable, leakable to version control, and extractable through prompt injection without requiring a zero-day. Obsidian Security's 2025 AI Agent Security Report found 90% of deployed agents hold roughly ten times more privilege than any single task requires. The blast radius of a compromised static credential is not bounded by its intended scope; it is bounded only by an attacker's lateral-movement capability. CVE-2025-68664 ("LangGrinch," CVSS 9.3) demonstrated the mechanism directly: a crafted prompt triggers unsafe deserialization of an agent framework's internal state, and the serialized output contains whatever credentials were sitting in the environment. | |
| **The failure pattern.** Static, long-lived credentials, API keys, shared service-account passwords, environment-variable-injected secrets, are structurally incompatible with agentic deployment. Every credential an agent carries is a durable attack surface: loggable, serializable, leakable to version control, and extractable through prompt injection without requiring a zero-day. Obsidian Security's 2025 AI Agent Security Report found 90% of deployed agents hold roughly ten times more privilege than any single task requires. The blast radius of a compromised static credential is not bounded by its intended scope; it is bounded only by an attacker's lateral-movement capability. CVE-2025-68664 ("LangGrinch," CVSS 9.3) demonstrated the mechanism directly: a crafted prompt triggers unsafe deserialization of an agent framework's internal state, and the serialized output contains whatever credentials were sitting in the environment. |
There was a problem hiding this comment.
can we link to the Obsidian security report? Also, I really like the blurb here on blast radius
|
|
||
| 1. **Workload identity** (AWS IRSA, GCP Workload Identity, Azure Managed Identity). The correct starting point for any containerized, single-cloud deployment. The platform attests to the workload's identity via the cluster's OIDC provider; the agent's SDK exchanges that attestation for short-lived (typically one-hour) cloud credentials automatically. No code changes required. No secret exists in the environment to extract. | ||
| 2. **Dynamic secrets** (HashiCorp Vault or equivalent). Covers what workload identity cannot reach: database credentials, third-party API keys, certificates. Vault issues a credential scoped to a single request with a configurable expiration (minutes to hours); the backing system cleans up the credential automatically on expiry. | ||
| 3. **Network-layer injection** for legacy systems that cannot be modified to support the above (a sidecar/proxy attaches credentials at the network layer; the agent never sees them). This is a containment measure for systems you cannot yet modernize, not an architectural destination , pair it with a roadmap toward Pattern 1 or 2. |
There was a problem hiding this comment.
Suggested change
| 3. **Network-layer injection** for legacy systems that cannot be modified to support the above (a sidecar/proxy attaches credentials at the network layer; the agent never sees them). This is a containment measure for systems you cannot yet modernize, not an architectural destination , pair it with a roadmap toward Pattern 1 or 2. | |
| 3. **Network-layer injection** for legacy systems that cannot be modified to support the above (a sidecar/proxy attaches credentials at the network layer; the agent never sees them). This is a containment measure for systems you cannot yet modernize, not an architectural destination, pair it with a roadmap toward Pattern 1 or 2. |
|
|
||
| ### 3.1 MCP Protocol Security | ||
|
|
||
| **The failure pattern.** MCP (Model Context Protocol, launched by Anthropic November 2024, now governed by AAIF under the Linux Foundation) is the de facto standard for agent-to-tool communication: 97M+ monthly SDK downloads, 10,000+ active public servers, first-class support across every major AI platform. Its trust model has two structural gaps the specification leaves open by design: OAuth 2.1 authentication is marked *optional*, and stdio transport , the most common local deployment mode - is explicitly *exempt* from the OAuth framework. First-party and third-party servers are indistinguishable at the protocol level. The documented attack classes: **tool poisoning** (malicious instructions hidden in a tool's description field, including via invisible Unicode tag characters U+E0000–U+E007F); **rug pulls** (a server behaves legitimately for weeks, then updates its tool definitions to request broader permissions or deliver manipulated content, with no client-side re-verification); **cross-server shadowing** (a malicious server reroutes a sensitive operation to a different, compromised server without notifying the operator); **sampling-based resource theft** and **conversation hijacking** (documented by Palo Alto Networks Unit 42). The incident record: the first malicious MCP server (Sept 2025, impersonating an email service, 1,643+ downloads before discovery), CVE-2025-6514 (CVSS 9.6, mcp-remote RCE, 437,000+ downloads at disclosure), and the Smithery hosting-platform breach (3,000+ downstream applications affected). |
There was a problem hiding this comment.
we should say "as of XXXXX date, there are 97M+ monthly downloads ....."
link for Palo Alto networks unit 42 and Smithery refs pls?
Also,
Suggested change
| **The failure pattern.** MCP (Model Context Protocol, launched by Anthropic November 2024, now governed by AAIF under the Linux Foundation) is the de facto standard for agent-to-tool communication: 97M+ monthly SDK downloads, 10,000+ active public servers, first-class support across every major AI platform. Its trust model has two structural gaps the specification leaves open by design: OAuth 2.1 authentication is marked *optional*, and stdio transport , the most common local deployment mode - is explicitly *exempt* from the OAuth framework. First-party and third-party servers are indistinguishable at the protocol level. The documented attack classes: **tool poisoning** (malicious instructions hidden in a tool's description field, including via invisible Unicode tag characters U+E0000–U+E007F); **rug pulls** (a server behaves legitimately for weeks, then updates its tool definitions to request broader permissions or deliver manipulated content, with no client-side re-verification); **cross-server shadowing** (a malicious server reroutes a sensitive operation to a different, compromised server without notifying the operator); **sampling-based resource theft** and **conversation hijacking** (documented by Palo Alto Networks Unit 42). The incident record: the first malicious MCP server (Sept 2025, impersonating an email service, 1,643+ downloads before discovery), CVE-2025-6514 (CVSS 9.6, mcp-remote RCE, 437,000+ downloads at disclosure), and the Smithery hosting-platform breach (3,000+ downstream applications affected). | |
| **The failure pattern.** MCP (Model Context Protocol, launched by Anthropic November 2024, now governed by AAIF under the Linux Foundation) is the de facto standard for agent-to-tool communication: 97M+ monthly SDK downloads, 10,000+ active public servers, first-class support across every major AI platform. Its trust model has two structural gaps the specification leaves open by design: OAuth 2.1 authentication is marked *optional*, and stdio transport, the most common local deployment mode - is explicitly *exempt* from the OAuth framework. First-party and third-party servers are indistinguishable at the protocol level. The documented attack classes: | |
| - **tool poisoning** (malicious instructions hidden in a tool's description field, including via invisible Unicode tag characters U+E0000–U+E007F) | |
| - **rug pulls** (a server behaves legitimately for weeks, then updates its tool definitions to request broader permissions or deliver manipulated content, with no client-side re-verification) | |
| - **cross-server shadowing** (a malicious server reroutes a sensitive operation to a different, compromised server without notifying the operator) | |
| - **sampling-based resource theft** | |
| - **conversation hijacking** (documented by Palo Alto Networks Unit 42). The incident record: the first malicious MCP server (Sept 2025, impersonating an email service, 1,643+ downloads before discovery), CVE-2025-6514 (CVSS 9.6, mcp-remote RCE, 437,000+ downloads at disclosure), and the Smithery hosting-platform breach (3,000+ downstream applications affected). |
|
|
||
| **Two-stream pipeline.** A compliance stream (action, approval, delegation, model-call, decision events; 100% capture, no sampling, cryptographic integrity, retention-locked storage) and an operational stream (verbose reasoning traces, diagnostics, performance metrics; sampled, short retention, basic checksums only). Assignment is by event category, not by system importance or volume , this also resolves most data-minimization tension, since personal data confined to the operational stream ages out quickly and was never written to the protected compliance stream at all. | ||
|
|
||
| **Kill-switch runbook as a forensic artifact, not just a containment one.** A usable runbook specifies four things explicitly: the exhaustive trigger conditions (so an on-call engineer is not exercising judgment under pressure about whether a threshold was met); the authority chain (who can trigger an immediate halt versus who must sign off on restart , these should differ); the ordered restart checklist (injection vector identified and mitigated, full credential rotation, log review of the window preceding the halt, explicit owner sign-off); and the forensic preservation requirement (execution log, pending approval queue, memory contents, and active tool invocations snapshotted to immutable storage *before* any state is cleared , an automated restart that clears state as part of its sequence will destroy the evidence the investigation depends on). |
There was a problem hiding this comment.
Suggested change
| **Kill-switch runbook as a forensic artifact, not just a containment one.** A usable runbook specifies four things explicitly: the exhaustive trigger conditions (so an on-call engineer is not exercising judgment under pressure about whether a threshold was met); the authority chain (who can trigger an immediate halt versus who must sign off on restart , these should differ); the ordered restart checklist (injection vector identified and mitigated, full credential rotation, log review of the window preceding the halt, explicit owner sign-off); and the forensic preservation requirement (execution log, pending approval queue, memory contents, and active tool invocations snapshotted to immutable storage *before* any state is cleared , an automated restart that clears state as part of its sequence will destroy the evidence the investigation depends on). | |
| **Kill-switch runbook as a forensic artifact, not just a containment one.** A usable runbook specifies four things explicitly: | |
| 1. the exhaustive trigger conditions (so an on-call engineer is not exercising judgment under pressure about whether a threshold was met) | |
| 2. the authority chain (who can trigger an immediate halt versus who must sign off on restart , these should differ) | |
| 3. the ordered restart checklist (injection vector identified and mitigated, full credential rotation, log review of the window preceding the halt, explicit owner sign-off) | |
| 4. the forensic preservation requirement (execution log, pending approval queue, memory contents, and active tool invocations snapshotted to immutable storage *before* any state is cleared , an automated restart that clears state as part of its sequence will destroy the evidence the investigation depends on). |
|
|
||
| **Kill-switch runbook as a forensic artifact, not just a containment one.** A usable runbook specifies four things explicitly: the exhaustive trigger conditions (so an on-call engineer is not exercising judgment under pressure about whether a threshold was met); the authority chain (who can trigger an immediate halt versus who must sign off on restart , these should differ); the ordered restart checklist (injection vector identified and mitigated, full credential rotation, log review of the window preceding the halt, explicit owner sign-off); and the forensic preservation requirement (execution log, pending approval queue, memory contents, and active tool invocations snapshotted to immutable storage *before* any state is cleared , an automated restart that clears state as part of its sequence will destroy the evidence the investigation depends on). | ||
|
|
||
| **Quick start, in sequence:** (1) establish per-agent identity before anything else , shared service-account identity makes every downstream attribution requirement impossible to satisfy; (2) instrument action, approval, and model-call events first, since they cover the highest-priority regulatory obligations per implementation hour; (3) propagate W3C Trace Context across delegation boundaries; (4) add per-entry signing and Merkle append with a published baseline root hash; (5) complete the remaining event categories; (6) stand up the operational stream and behavioral baselines (Section 5) last, since they have no value without the compliance stream already running underneath them. |
There was a problem hiding this comment.
Suggested change
| **Quick start, in sequence:** (1) establish per-agent identity before anything else , shared service-account identity makes every downstream attribution requirement impossible to satisfy; (2) instrument action, approval, and model-call events first, since they cover the highest-priority regulatory obligations per implementation hour; (3) propagate W3C Trace Context across delegation boundaries; (4) add per-entry signing and Merkle append with a published baseline root hash; (5) complete the remaining event categories; (6) stand up the operational stream and behavioral baselines (Section 5) last, since they have no value without the compliance stream already running underneath them. | |
| **Quick start, in sequence:** | |
| 1. establish per-agent identity before anything else, shared service-account identity makes every downstream attribution requirement impossible to satisfy | |
| 2. instrument action, approval, and model-call events first, since they cover the highest-priority regulatory obligations | |
| 3. propagate W3C Trace Context across delegation boundaries | |
| 4. add per-entry signing and Merkle append with a published baseline root hash | |
| 5. complete the remaining event categories | |
| 6. stand up the operational stream and behavioral baselines (Section 5) last, since they have no value without the compliance stream already running underneath them. |
Please rm the "Section 5" comment and put the name of the thing it is referencing and link within this doc 🙏
|
|
||
| Maturity: GA (production-ready), Beta (publicly released with caveats), Experimental. Cost: Free, Moderate ($100–$2,000/mo at team scale), Enterprise. Status reflects early 2026; re-verify before procurement. | ||
|
|
||
| | Area | Tool | Type | Maturity | Cost | Notes | |
There was a problem hiding this comment.
Suggested change
| | Area | Tool | Type | Maturity | Cost | Notes | | |
| | Area | Tool | Type | Maturity | Cost | Notes | Link | |
We should link out to these resources pls
| |---|---|---|---|---|---| | ||
| | Secrets - dynamic | HashiCorp Vault Community | Open Source | GA | Free | BSL license; dynamic secrets, credential issuance | | ||
| | Secrets - workload identity | AWS IRSA / GCP WIF / Azure Managed Identity | Managed | GA | Free | Cloud-native; no cost beyond platform | | ||
| | Tool invocation - MCP static scan | Cisco MCP Scanner | Open Source | Beta | Free | Multi-engine; YARA + LLM-as-judge | |
| | Secrets - dynamic | HashiCorp Vault Community | Open Source | GA | Free | BSL license; dynamic secrets, credential issuance | | ||
| | Secrets - workload identity | AWS IRSA / GCP WIF / Azure Managed Identity | Managed | GA | Free | Cloud-native; no cost beyond platform | | ||
| | Tool invocation - MCP static scan | Cisco MCP Scanner | Open Source | Beta | Free | Multi-engine; YARA + LLM-as-judge | | ||
| | Tool invocation - MCP runtime | Invariant mcp-scan | Open Source | Beta | Free | Runtime constraint enforcement and logging | |
There was a problem hiding this comment.
isn't this what I linked from Snyk above? Is it still with Invariant or Snyk now?
sicoyle
reviewed
Aug 10, 2026
sicoyle
left a comment
sicoyle
left a comment
There was a problem hiding this comment.
almost done, but thank you for putting this together and giving us a phenomenal starting point - you rock!! 🙌 👏
I will finish my review after our current WG meeting :)
sicoyle
reviewed
Aug 10, 2026
| | Supply chain - skill scanning | Cisco Skill Scanner | Open Source | Beta | Free | Static + behavioral dataflow + optional LLM review | | ||
| | Supply chain - skill scanning | Snyk Agent Scan | Open Source / Commercial | Beta | Free/Moderate | 90–100% recall on confirmed-malicious skills in vendor testing | | ||
| | Supply chain - SBOM baseline | Syft / Grype (Anchore) | Open Source | GA | Free | Traditional SBOM + CVE scanning; CI/CD native | | ||
| | Guardrails - HITL orchestration | LangGraph | Open Source | GA | Free | Static/dynamic interrupts; native checkpointing | |
There was a problem hiding this comment.
Suggested change
| | Guardrails - HITL orchestration | LangGraph | Open Source | GA | Free | Static/dynamic interrupts; native checkpointing | | |
| | Guardrails - HITL orchestration | LangGraph | Open Source | GA | Free | Static/dynamic interrupts; native checkpointing | | |
| | Guardrails - HITL orchestration | Dapr Agents | Open Source | GA | Free | Durable agent workflows with deterministic replay + native HITL interrupts built on Dapr Workflows. | |
| | Guardrails - HITL orchestration | LangGraph | Open Source | GA | Free | Static/dynamic interrupts; native checkpointing | | ||
| | Guardrails - input/output | NeMo Guardrails (NVIDIA) | Open Source | GA | Free | Input/output moderation, jailbreak detection | | ||
| | Guardrails - PII | Presidio (Microsoft) | Open Source | GA | Free | PII identification/anonymization at ingestion | | ||
| | Guardrails - inter-agent comms | Dapr | Open Source | GA | Free | mTLS sidecar isolation between agents | |
There was a problem hiding this comment.
Suggested change
| | Guardrails - inter-agent comms | Dapr | Open Source | GA | Free | mTLS sidecar isolation between agents | | |
| | Guardrails - inter-agent comms & policy | Dapr | Open Source | GA | Free | mTLS sidecar isolation between agents, service-invocation access-control allowlists, OPA policy middleware, secrets API abstraction over Vault/Cloud stores, workflow level tool-access policies (to gate/block tools), PII scrubbing and input/output hooks | |
| | Guardrails - input/output | NeMo Guardrails (NVIDIA) | Open Source | GA | Free | Input/output moderation, jailbreak detection | | ||
| | Guardrails - PII | Presidio (Microsoft) | Open Source | GA | Free | PII identification/anonymization at ingestion | | ||
| | Guardrails - inter-agent comms | Dapr | Open Source | GA | Free | mTLS sidecar isolation between agents | | ||
| | Eval - pre-deployment | OWASP FinBot (genai.owasp.org) | Framework / CTF | GA | Free | Hands-on Agentic Top 10 exposure | |
There was a problem hiding this comment.
Suggested change
| | Eval - pre-deployment | OWASP FinBot (genai.owasp.org) | Framework / CTF | GA | Free | Hands-on Agentic Top 10 exposure | | |
| | Guardrails - execution isolation | gVisor / Firecracker | Open Source | GA | Free | Kernel- and microVM-level sandboxing for agent-generated code and tool execution with ephemeral per-task environments | | |
| | Eval - pre-deployment | OWASP FinBot (genai.owasp.org) | Framework / CTF | GA | Free | Hands-on Agentic Top 10 exposure | |
Comment on lines
+160
to
+161
| | Source | Type | Application | | ||
| |---|---|---| |
There was a problem hiding this comment.
would be super nice to have links here too pls
flucktemberg-sap
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Out of scope (by design)
Identity and delegated authorization architecture (SPIFFE/SVID, RFC 8693, others) is explicitly excluded as this lives in the Identity and Trust WG.