Why this signal matters
OpenSSF’s April 2026 tech talk recap on securing agentic AI is a useful field signal because it frames agentic AI as a stack problem, not just a model problem. The recap highlights agentic-AI threat modeling, SAFE-MCP, and the need for SBOM visibility across a multi-layer open-source AI stack.
Read with CISA’s AI data-security best practices from CISA, NSA, FBI, and partners, the operational point is straightforward: when an AI agent can interact with tools, data, and open-source components, counsel should ask for evidence of boundaries and approvals before the workflow becomes routine.
This is not a prediction about new liability rules. It is a control review for teams adopting agentic AI in environments where internal data, developer tooling, and open-source software are already interconnected.
The hinge: agents change the evidence question
For technology counsel, the key issue is evidentiary. If an agent produces an unexpected result, exposes data, or acts through a tool in a way the business did not anticipate, the first question will be basic: what was the agent able to access, what components were in the stack, what data was available, and who approved the workflow?
OpenSSF’s focus on threat modeling, tool trust boundaries, and SBOM visibility points to that same evidence gap. CISA’s guidance adds the data-security lens across the AI lifecycle: development, testing, deployment, and operation. Together, they support a practical requirement that agent deployments be documented as operational systems, not treated as informal productivity experiments.
Five control questions for counsel and platform teams
1. What tools can the agent reach?
Start with a plain-language tool map. Identify the internal tools, developer tools, and open-source components that the agent can interact with. Then ask whether the team has described the trust boundary for each tool interaction.
Useful review questions include:
- What tool connections are enabled for the agent workflow?
- Who approved those tool connections?
- What actions can the agent initiate through those tools?
- Is there a documented test or deployment approval for the workflow?
- What would count as unexpected agent behavior requiring escalation?
The goal is not to slow every experiment. The goal is to avoid a situation where no one can later explain the agent’s permitted operating range.
2. What data is available to the agent?
CISA’s best-practices guidance focuses on securing data used to train and operate AI systems and notes that data security affects the accuracy, integrity, and trustworthiness of AI outcomes across the lifecycle. For counsel, that means the data review should not stop at training data.
Ask engineering and product owners to identify the data available during development, testing, deployment, and operation. For internal-use systems, the review should expressly address sensitive internal information and trade-secret exposure. If an agent can use operational data, the control owner should be able to describe what data categories are in scope and what data is excluded.
A practical artifact is a short data-access record for each material agent workflow: data sources available, lifecycle stage, approving owner, and any known limitations.
3. What SBOM or provenance evidence exists for the AI stack?
OpenSSF’s recap highlights the need for SBOM visibility across a multi-layer open-source AI stack. That matters because agentic workflows may depend on more than one visible application. The operating chain can include open-source components, AI components, and tool integrations that are not captured in a simple product description.
Counsel and procurement teams should ask whether the supplier or internal platform owner can provide SBOM visibility or comparable dependency evidence for the AI components involved. The question should be framed as an evidence request, not a formality: what components are in the stack, where is that information maintained, and how will changes be reflected?
This is especially important where agent workflows are added to existing developer platforms. The legal and operational review should not assume that current software inventory practices automatically cover the agent layer.
4. What approval record exists before deployment?
Agent workflows should have a documented path from test to deployment. The approval record does not need to be elaborate, but it should show that someone reviewed tool access, data access, component visibility, and expected behavior before operational use.
At minimum, the record should answer:
- What was tested?
- What tool and data boundaries were reviewed?
- Who approved deployment?
- What limitations or unresolved risks were noted?
- What escalation path applies if behavior or data exposure is unexpected?
This kind of record is useful for legal, security, and product teams because it creates a shared version of what the deployment was intended to do.
5. What incident documentation will be created if the agent behaves unexpectedly?
OpenSSF’s threat-modeling focus and CISA’s lifecycle data-security framing both point toward incident readiness. Teams should define escalation triggers before deployment, not after a failure.
Examples of review triggers include unexpected agent behavior, unanticipated data exposure, or a discovered gap in component visibility. The important control is the documentation habit: when a trigger occurs, the team should preserve the facts needed to understand the tool boundary, data context, component stack, and approval history.
Contract and procurement questions
For third-party agent tools or managed AI components, procurement should avoid relying only on high-level AI descriptions. Counsel can ask:
- Does the provider describe the tool boundaries for agent behavior?
- Does the provider address data used to train or operate the AI system?
- Can the provider supply SBOM visibility or comparable evidence for relevant AI and open-source components?
- Does the provider support documentation of testing, deployment approval, and incident escalation?
- Are limitations or exclusions clearly described?
These questions are not a substitute for a full security review. They are a way to make the legal and operational record match the way agentic AI actually functions: through tools, data, and dependencies.
What to do now
Teams piloting agentic AI should select a small number of workflows and run the five-question review before broader rollout. The most useful output is a lightweight control packet: tool map, data-access record, SBOM or dependency evidence, deployment approval, and escalation triggers.
Where the answers are incomplete, counsel can help decide whether the workflow should remain experimental, move forward with limits, or wait for better documentation. The immediate objective is not perfection. It is to prevent agentic AI from becoming embedded before the organization can explain its boundaries.