JFrog DORA Compliance: 5 Ways to Tame Shadow AI in DevOps

JFrog DORA compliance support landed on October 21, 2026, when the company added a ready-made DORA framework and AI verification policies to its AppTrust release-governance product.

It also expanded JFrog AI Security with a feature that hunts for AI tools developers install without telling anyone. Put together, the two announcements point at the same uncomfortable truth. AI agents write code faster than most governance processes can review it, and regulators in Europe want signed proof for every release. Here is what was announced and what DevOps teams can learn from it, even if you never buy the product.

1. Turn DORA into policy as code

The Digital Operational Resilience Act is a headache for any team that ships software to EU financial entities. JFrog’s AppTrust now includes pre-mapped Policy as Code rules across five areas: IT change management, source code and component integrity, vulnerability and patch management, resilience testing, and incident management.

Teams switch on the controls that apply to them. Each control links to a specific DORA requirement, and a score shows how much of the framework is active. The source article on JFrog AppTrust adding the DORA framework has the full list.

The lesson is bigger than one vendor. If a compliance requirement lives in a PDF, someone will forget it. If it lives in your pipeline as a check that fails the build, it gets enforced every time.

2. Let AI check AI, with evidence attached

AI Verification Policies let teams write rules in plain language and have LLMs check each release against them. One example from JFrog: confirm that a pull request actually matches the original Jira ticket. Every check produces signed evidence.

The goal is to catch out-of-scope code, unauthorized backdoors and unapproved architecture changes, whether they came from an agent or a human developer. CTO Yoav Landman framed the challenge neatly: can you prove trust in what you shipped, continuously, at the cadence AI agents now set?

So yeah, this is a real shift. Review is moving from “a person skimmed the diff” to “a system produced a signed record that the change matched its intent.”

3. Find the shadow AI on developer laptops

This is the part I find most useful. Local Shadow AI Detection scans developer workstations for skills, plugins and MCP servers, regardless of which repository or marketplace they came from. It can roll out through the JFrog Agent Plugin, MDM, or agent harness settings. The scan is deterministic and runs on the machine, and only metadata and a risk assessment go back to the platform.

CEO Shlomi Ben Haim put it bluntly: developers are already running AI agents that organizations cannot see. Those tools run with the developer’s own permissions and credentials. They get installed through Git, Slack, marketplaces or a plain ZIP file. Ask your own team who installed what, and whether anyone approved it. Most can’t answer. Details are in the Techzine report on JFrog’s shadow AI detection.

4. Bring your own LLM key for scanning

JFrog also added AI Asset Scanning with Bring Your Own LLM Key. Semantic scans run through the customer’s own model account, with prompts and skills going straight to the customer’s endpoint and no JFrog gateway in between. The customer’s model provider bills for usage. For self-hosted customers, BYOK is the only way to use the feature.

At launch it supports Anthropic Opus 4.8, OpenAI GPT 5.6 Sol and Google Gemini 3.1 Pro. Both new security features are available now to JFrog Unified Security and Ultimate Security users.

For regulated teams, the design choice matters. Sensitive prompts and internal skills never pass through a third party. That is a pattern worth copying in your own tooling.

5. Plan for the Cyber Resilience Act too

DORA is not the only EU rule pressing on engineering teams. AppTrust also monitors released components for vulnerabilities, generates an SBOM per release, and keeps scan history and remediation actions. Teams can prepare a report within 24 or 72 hours, which lines up with Cyber Resilience Act reporting timelines.

The same week showed why that readiness matters. Critical PHP flaws forced thousands of teams to ask what they were running and where, as we covered in our PHP vulnerabilities guide. An SBOM per release turns that scramble into a search query.

What small and mid-sized teams can do without a big budget

You do not need an enterprise platform to start. Begin with an approved list of AI tools, plugins and MCP servers. Publish it. Ask developers to register anything outside it. Next, require every release to carry an SBOM and a record of who approved it. Then add one automated check that compares each pull request with its ticket, even if it is a simple script at first.

It will not be perfect on day one. Fine. Governance improves by iteration, much like code does. If cost is your concern, our piece on FinOps discipline for runaway AI spending shows how to keep AI tooling usage visible and budgeted.

Key Takeaways

• Compliance as code: AppTrust’s DORA framework maps five control areas to specific requirements and scores coverage.
• Signed evidence: AI Verification Policies check releases against plain-language rules and record the result.
• Shadow AI is real: Local detection finds unapproved skills, plugins and MCP servers on developer machines.
• Keep data close: BYOK scanning sends prompts directly to your own model endpoint.
• Prepare for CRA: Per-release SBOMs and 24 or 72 hour reporting readiness are becoming standard expectations.

How TecniForge Can Help

At TecniForge, we help businesses navigate these technology shifts. Whether you need custom software development, AI integration, or cloud migration, our team builds scalable solutions. We can help you set up CI/CD pipelines with built-in security checks, SBOM generation and approval workflows that fit your size and budget. Talk to our experts.

If an auditor asked tomorrow which AI tools run on your developers’ machines, how long would it take you to answer?