Details
How platform teams can give AI coding agents useful autonomy while enforcing artifact-level security, policy, and auditability.
AI agents can now create code, select dependencies, configure repositories, and initiate builds, increasing both development speed and software supply chain exposure. In this session, JFrog and AWS demonstrate a governed agentic workflow that combines the JFrog Power for Kiro with AWS CodeBuild, Amazon ECR, Amazon Bedrock AgentCore, JFrog Artifactory, and JFrog Curation. The workflow allows agents to assist developers while enforcing security policies before packages enter the organization or reach runtime.
AI coding agents can consume many third-party packages while building a single application. Each direct or transitive dependency may come from a different publisher or repository, creating another potential point of compromise.
Organizations remain responsible for the integrity of the software they deliver, regardless of whether a human or an AI agent selected the underlying packages.
The speakers recommend applying zero-trust principles at the artifact level. Every requested package should be evaluated against organizational policy before it is downloaded or incorporated into a build.
This gives agents room to work while preventing their speed or autonomy from bypassing established software supply chain controls.
JFrog Curation sits between package consumers and public repositories. It evaluates package requests against policies covering risks such as critical vulnerabilities, malicious packages, prohibited licenses, and immature packages.
When a requested package violates policy, the download is blocked and the build fails before the resulting container image is created or deployed.
The JFrog Power for Kiro allows developers to interact with the JFrog platform from an AI-native IDE. In the demonstration, a developer uses natural-language instructions to create a project and a best-practice repository structure for npm and Docker.
The integration uses JFrog CLI capabilities behind the scenes, reducing the need to navigate the user interface, consult documentation, or assemble API calls manually.
A governed workflow should not merely fail silently. Developers need to understand which policy was violated, which dependency caused the failure, and which version or action may resolve it.
The demonstrated workflow records blocking events, displays vulnerability information, and supplies remediation recommendations through build logs and JFrog Curation audit events.
JFrog Curation evaluates incoming packages before they enter the organization. JFrog Xray scans packages already stored in Artifactory and can respond when new vulnerabilities are disclosed after approval or deployment.
Together, these controls provide an initial gate for incoming dependencies and a continuing defense for packages already in use.
Agent speed should not determine security policy
Practical implication: Apply the same package and artifact policies to AI-generated workflows that apply to human-led development.
Package checks should occur before ingestion
Practical implication: Evaluate dependencies before they are downloaded, incorporated into an image, or stored in an internal repository.
Transitive dependencies require equal scrutiny
Practical implication: Inspect every package request, including dependencies pulled indirectly by another package.
Policies should reflect organizational risk tolerance
Practical implication: Define rules for CVSS thresholds, malicious packages, licenses, package maturity, and other relevant supply chain risks.
New policies can be evaluated safely
Practical implication: Use dry-run policies to measure their potential effect before enforcing them across development workloads.
Failed gates must be actionable
Practical implication: Give developers the policy reason, affected dependency, supporting security information, and recommended remediation.
Agentic workflows need centralized auditability
Practical implication: Preserve build logs, policy decisions, curation responses, and deployment activity in systems security and platform teams can review.
Why are AI agents software supply chain targets?
AI agents can select and download numerous third-party packages while creating applications. A compromised, malicious, vulnerable, or insufficiently vetted dependency can therefore enter a workflow quickly unless package requests are governed.
What is the JFrog Power for Kiro?
It is an integration that teaches the Kiro AI-native IDE how to interact with the JFrog platform. It can help perform activities such as artifact search, project and repository creation, security analysis, and policy-related operations from within the development environment.
What does JFrog Curation do?
JFrog Curation evaluates incoming open-source package requests against organizational policies. If a package violates an enforced policy, Curation blocks the download before the package enters the organization or becomes part of a build.
How is JFrog Curation different from JFrog Xray?
Curation controls packages at ingress, before they enter Artifactory. Xray scans packages already stored in Artifactory and can identify risks discovered after those packages were initially approved.
What risks can Curation policies address?
The demonstration shows policies for critical CVSS scores, malicious packages, prohibited licenses, and immature packages. Organizations can select from available policies and create custom rules based on their requirements.
Can Curation evaluate transitive dependencies?
Yes. According to the speakers, every package request is evaluated, including packages pulled indirectly as dependencies of another package.
Does package evaluation significantly slow builds?
In the demonstrated implementation, the speakers reported that Curation added only milliseconds per package and a small number of seconds to a build lasting several minutes. Actual performance will depend on the environment and implementation.
Can developers bypass the security gate?
In the demonstrated AWS CodeBuild workflow, the gate is integrated into the build and cannot be bypassed within that governed path. Organizations still need broader controls for activity performed outside the approved pipeline.
What happens if a vulnerability is discovered after deployment?
JFrog Xray can rescan or reevaluate packages already stored in Artifactory. A package that was allowed previously may later be blocked when a newly disclosed vulnerability causes it to violate policy.
Can teams test a policy before enforcing it?
Yes. Policies can be placed in dry-run mode, allowing teams to record potential violations and assess their impact without immediately blocking workloads.
Ken Underhill: Hello, everyone, and welcome to today’s DZone webinar, “When Your Newest Developer Is an AI Agent: Running the Software Supply Chain in the Era of AI.”
My name is Ken Underhill, and I’ll be your host for today’s session.
AI agents are quickly becoming active participants in software development. They can write code, pull dependencies, interact with tools, and move work forward at a speed that traditional software supply chains were not necessarily designed to handle.
That creates an important challenge for platform and development teams: How do you give AI agents enough autonomy to be useful without losing the governance, security, and visibility you need to trust what they are doing?
Before we get into that, I have a few housekeeping notes. We’ll share the on-demand recording after today’s session. If you have questions during the presentation, please submit them using the Q&A tab. We’ll try to address as many as possible during the Q&A portion at the end.
Today, JFrog and AWS will take a practical look at governed agentic development inside a real developer workflow.
You’ll gain practical insight into how agentic development is changing day-to-day work across the software supply chain, including where it can introduce risk and where it can reduce friction.
You’ll also learn what it takes to give AI agents useful autonomy while maintaining appropriate governance, and how the JFrog Power for Kiro can bring artifact search, repository and project operations, security insights, and policy enforcement into AI-native development workflows.
I’m pleased to introduce today’s speakers. Joining us from AWS is Arik Yakir, Senior Partner Solutions Architect. From JFrog, we have Eldad Assis, Principal DevOps Architect.
Arik and Eldad, thank you for joining us. I’ll turn it over to you.
Eldad Assis: Thank you, Ken.
Arik Yakir: Thank you, Ken. I’m Arik from AWS, and I’m a Partner Solutions Architect.
Eldad and I developed a use case that combines the value of JFrog and AWS. We’d like to present the architecture and use case, including a live demonstration that was recorded in advance.
We can also provide the artifacts, architecture, and flow from this demonstration and discuss them with you offline. We’ll be available to help you through your development journey in the AI era.
Why are AI agents software supply chain targets?
AI agents and AI coding assistants can consume dozens of third-party packages while building a single solution or function. As the solution grows in complexity, the number of dependencies can increase significantly.
These packages, SDKs, clients, and libraries can come from dozens or even hundreds of remote publishers and repositories. Each can represent a potential point of compromise.
Some risks are introduced intentionally by attackers. Others may result from inadequate development or testing, or from the use of very new components.
As the developers and publishers delivering a solution to customers, you are responsible for maintaining the integrity and security of that solution.
Eldad Assis: A single compromised package can literally bring down a company. Worse, it could affect the company’s customers.
We have seen examples over the past several years. Consider SolarWinds, where a software supply chain attack affected the company’s product and compromised its customers.
Many solutions have been released to improve software supply chain security. However, the growing use of autonomous agents raises the stakes. You are giving agents greater autonomy and may feel that you are losing control.
In this presentation, we’ll show how you can maintain control while benefiting from the growing use of agents.
Arik Yakir: The approach we’re presenting applies zero-trust principles at the artifact level.
JFrog and AWS work together to break down the dependencies and development flow, creating a policy-driven, artifact-level hard gate.
The pipeline is implemented using AWS services and gated by JFrog as an external service. The integrations communicate throughout the development lifecycle, including dependency checks, artifact downloads, package deployment, and related operations.
We’ll show how this back-and-forth integration works.
Eldad Assis: The solution we’re presenting relies on a security gate called JFrog Curation.
JFrog Curation acts like a firewall. It sits between package consumers—whether developers, CI/CD pipelines, or production environments—and the open-source ecosystem.
Every package download is evaluated through Curation. If the package violates a policy, the download is blocked.
The evaluation is immediate because it does not require an on-demand scan. The necessary information has already been prepared, allowing Curation to block a package that violates policy.
For example, if a policy fails while you are building a Docker image, that image is never produced. Nothing reaches the destination repository, whether that is JFrog Artifactory or Amazon Elastic Container Registry in this example.
This applies protection as far left as possible, either at the developer workstation or within CI/CD.
Arik Yakir: Let’s talk about the pipeline.
The build-to-deployment pipeline is implemented using AWS CodeBuild. The CodeBuild flow has three primary stages.
The first is the pre-build stage, during which we perform setup and authentication and install the necessary packages and tools.
The second is the build stage. We create the Docker image and interact with JFrog Curation.
The third is the post-build stage. On the left side of the diagram, you can see a successful path. On the right, you can see a failed path.
A successful build proceeds to Amazon ECR, the AWS container registry. The package is then deployed to Amazon Bedrock AgentCore, where the agent runs.
A failed post-build stage displays the failure reason and remediation recommendations.
The end-to-end software development lifecycle begins from the developer’s perspective.
The developer uses Kiro, an AWS AI-native IDE with agentic capabilities. We’ll demonstrate the JFrog Power for Kiro, which teaches Kiro how to interact with the JFrog platform.
The developer then triggers the build script, initiating the software development lifecycle through CodeBuild.
The project is packaged and uploaded to an Amazon S3 bucket connected to CodeBuild. CodeBuild initiates the CI process and starts the Docker build, with requests evaluated through JFrog Curation.
Eldad Assis: JFrog Curation evaluates download requests using the JFrog Catalog, which holds the relevant package information.
It compares each requested package with the organization’s policies. A series of policies can be evaluated. If a policy is violated, Curation blocks the download and fails the workflow.
If every dependency downloaded through Artifactory is approved, the Docker image is produced and uploaded to Amazon ECR.
Arik Yakir: The image then moves to Amazon Bedrock AgentCore, which provides the agent’s runtime environment.
AgentCore is a serverless AWS service. Instead of maintaining continuously running infrastructure, customers pay according to runtime and resource consumption.
AgentCore is the service we use to deploy the agent created during the initial steps in Kiro.
Eldad Assis: Here is a simplified view of the JFrog architecture.
The local consumer could be a developer, CI pipeline, or production environment pulling container images or other agent assets.
The request reaches JFrog Artifactory. In this example, Artifactory has a remote repository pointing to PyPI, the public Python package repository.
Each request is evaluated through JFrog Curation. Curation reviews information from the JFrog Catalog and either approves the download or blocks it.
You can also see JFrog Xray in the architecture. Unlike Curation, Xray scans packages already stored in Artifactory.
Xray is not the primary focus of this session. We’re concentrating on Curation.
Arik Yakir: Let’s zoom out and look at the end-to-end architecture.
On the right is the JFrog platform architecture Eldad just described. Starting from the left, a developer uses Kiro to create the agent.
The build stage packages the project into a ZIP file and uploads it to Amazon S3. CodeBuild executes the pre-build, build, and post-build stages while interacting with the JFrog platform.
Depending on the results, the post-build stage also interacts with Amazon ECR and Amazon Bedrock AgentCore.
If a failure occurs, the pipeline generates and displays additional evidence and artifacts.
Eldad Assis: We’re going to demonstrate two paths.
The first is a broken path in which we trigger several policy violations. We’ll show how the violations appear and how developers can determine what needs to be fixed.
Arik Yakir: We’ll also demonstrate a successful path.
The workflow will pass all Curation checks, deploy to Amazon ECR, and then deploy to the AgentCore runtime, where we’ll run the agent.
In the broken-path screenshot, you can see that the pre-build stage has completed and the pipeline has moved to the build stage. As we move down the log, we can see the response from JFrog.
Eldad Assis: The message is self-explanatory. The package was blocked because a critical vulnerability was found.
The policy condition was a CVSS score of nine or higher. The log shows the vulnerabilities associated with the package and provides remediation recommendations.
Arik Yakir: The successful path is similar, but every check passes.
The pipeline proceeds to Amazon ECR, as shown in the third step at the bottom.
We captured these screenshots in advance because runtime logs can move quickly, even when we try to pause between stages.
Now, let’s go to the demonstration.
Kiro is an IDE based on Visual Studio Code. You can see the repository, dependency, and installation views. Some of these are familiar plugins, including Amazon Q and the AWS Toolkit.
The important view I want to highlight is the Powers panel.
You can see many Powers developed and approved for Kiro that help it work with different partner environments. The panel includes third-party partners and AWS services.
Even though the IDE has AI capabilities, its underlying model does not automatically understand every AWS service and third-party platform. Powers provide that specialized knowledge.
This is the JFrog Power for Kiro. It is developed and maintained by JFrog in a GitHub repository.
We use it to create a natural-language, agentic interface for the JFrog environment.
Here, we’re performing a quick check of the JFrog platform that is already running and connected to Kiro. At this point, we are simply checking the environment using JFrog CLI through the JFrog Power for Kiro.
In the next step, we’ll create something new, and Eldad will explain more.
Eldad Assis: While that runs, I’ll add some context about the JFrog Power.
If you’re familiar with JFrog Skills or the JFrog MCP server, the Power brings related capabilities together into a package supported by Kiro.
One of its most important functions is simplifying the interface between the user and the JFrog platform.
JFrog is a complex platform, and not everyone knows every feature or best practice. The agentic interface helps users perform operations while applying relevant platform knowledge.
Here, we’re creating a project with repositories. We may not know every best practice for creating that project or those repositories, so we ask Kiro to do it.
The JFrog Power contains the necessary information and follows JFrog best practices.
We receive a project and repositories for npm and Docker without having to specify every repository type.
As you’ll see, it creates remote, local, and virtual repositories. Everything is configured according to the relevant practices, including Curation, with minimal manual effort.
Behind the JFrog Power and JFrog Skills is JFrog CLI.
Existing JFrog customers may already know JFrog CLI. It is a versatile command-line tool for interacting with the JFrog platform and is designed for automation.
By using it through the JFrog Power for Kiro and JFrog Skills, developers can access the necessary APIs to configure their JFrog environment and applications.
This reduces the complexity of navigating the user interface and searching the documentation.
We only asked Kiro to create a project called RC Test and add repositories for npm and Docker. The project now exists.
Inside the project, we can see that six repositories were created: remote, local, and virtual repositories for both npm and Docker.
Arik, back to you.
Arik Yakir: This is a restaurant-recommendation agent. It is a simple Python agent implemented using the Strands Agents SDK.
We create a system prompt that provides backend instructions and import a large language model running on Amazon Bedrock.
The project also contains city coordinates and tool calls. It is intentionally simple for demonstration purposes.
These scripts will be used during the CodeBuild deployment.
The Bedrock AgentCore YAML file provides the configuration needed to run the agent on Bedrock AgentCore.
The agent runs as a container. Its entry point allows the container to launch within the AgentCore runtime.
Next, we review the build specification. This orchestrates the CodeBuild process and defines the three stages. Each stage calls the necessary execution or script files.
This is the primary Python file for the agent.
The important part is the requirements file. Let’s pause the demonstration there.
The project and agent remain the same. The same steps are executed through CodeBuild and evaluated by JFrog Curation.
The only difference is that we created a vulnerable requirements file containing a package that will fail the Curation policy check.
We also created a separate version containing an immature package that had been released only a few days before the recording. That package triggers a different policy.
Here, you can see the package version we marked for Curation testing. The standard requirements file does not contain that vulnerable dependency—or contains the remediated version instead.
Both paths use the same build script. A flag determines which requirements file is included when the ZIP package is uploaded to Amazon S3.
The project and agent are the same; only the dependency list changes.
This is the clean version, which does not contain the vulnerable package. It still contains the immature package for the second policy demonstration.
Eldad Assis: Let’s return to the Curation policies.
Here are several examples. In this configuration, GPL licenses are blocked. Packages with critical vulnerabilities and a CVSS score of nine or higher are blocked. Malicious packages are also blocked.
This is only a selection of the policies available. The library includes many additional options, and customers can create their own.
We also configured a policy for immature packages, which is another valuable control.
Arik Yakir: Let’s look more closely at the build script.
This file triggers the workflow and can run from the developer’s laptop inside or outside Kiro.
It contains the relationships with the environment, including which requirements file should be used and how to switch between them. It also defines what should be included in the ZIP archive uploaded to the S3 bucket for CodeBuild.
The process uses simple shell commands to create the archive and upload it.
Parameters are hashed, and secrets are retrieved at runtime from AWS Secrets Manager. We do not store credentials in the Docker files.
Here is the Docker build, including the commands used during execution and the logging files that can be produced when necessary.
Now, we’ll run the build in break mode.
The script creates the ZIP archive, uploads it, and starts the build.
We then open the AWS console. In CodeBuild, we can see a new build in progress and follow its logs during execution.
The build started a few seconds ago. It is currently in the pre-build setup stage.
We install JFrog CLI, the required AWS tools, and other dependencies inside the CodeBuild environment.
Because CodeBuild is serverless and starts with a fresh environment, the required tools are installed during each execution. This also allows the workflow to use current versions.
As we continue through the log, pip begins collecting and downloading the packages.
We can see a red error associated with the test dependency. Further down, the pipeline skips the push to Amazon ECR and displays the dependency errors.
It also shows recommended versions that can remediate the identified vulnerabilities.
Eldad Assis: This package violated the policy blocking vulnerabilities with a CVSS score of nine or higher.
Arik Yakir: We then run the same workflow with a different policy condition. This time, the build fails because the package is less than 14 days old and violates the immature-package policy.
Eldad Assis: If you return to the Curation interface and open the audit events, you can see every blocking event recorded there.
The interface provides the same information shown in the console, so teams can return to it later. You can review statistics, violation details, and remediation steps. This information can also be extracted when needed.
Arik Yakir: Next, we run the build again without the break-mode flag. This produces the successful path.
The approved requirements file is placed into the S3 bucket, and CodeBuild starts the deployment.
We follow the new execution and see that there is no error or Curation policy violation.
The process downloads and evaluates all dependencies, completes the installation, and prepares the image for Amazon ECR.
Everything completes successfully.
Each dependency has been approved by Curation. The container image is pushed to Amazon ECR and deployed to Amazon Bedrock AgentCore.
The log displays the agent ID and its AWS Amazon Resource Name.
We then open the Bedrock AgentCore runtime and test the deployed agent with a simple prompt asking it to recommend a restaurant in New York for a group of friends.
The agent responds after executing tools that search for restaurants and availability.
This demonstrates a successful end-to-end deployment after the project passes all Curation checks.
In this example, the requirements file lists more than 100 packages. Some of those packages have their own dependencies that must also be downloaded. Those transitive dependencies are also evaluated by JFrog Curation.
That completes the workflow demonstration.
Eldad Assis: Let’s close with several takeaways.
You saw the demonstration, the pipeline, the policy enforcement, and how violations appear during execution.
This type of enforcement is valuable for any automated workflow, especially one involving AI agents.
The first principle is shift-left security. The sooner you identify a problem, the faster and less expensive it is to fix.
Vulnerabilities and malicious packages should be blocked during development. If a package is blocked as soon as someone attempts to retrieve it, the organization receives protection at the earliest possible stage.
The second principle is policy-driven security.
No single policy fits every organization. Teams can define rules and apply them to specific repositories or across the organization. One policy can protect an organization’s entire repository portfolio.
The third principle is minimizing developer friction.
We designed the solution so the security controls do not unnecessarily disrupt developers. Curation can also help identify compliant package versions, although that capability is outside the scope of this presentation.
The less friction developers encounter, the more easily teams can benefit from the autonomous nature of agents without avoiding the governed workflow.
Arik Yakir: Another important principle is complete software supply chain visibility.
We implemented this example using AWS CodeBuild, although other services such as AWS CodePipeline can also participate in a broader implementation. We selected CodeBuild because it is a core service that is relatively straightforward to use.
The logs flow into a unified location. Ultimately, the relevant output appears in the CodeBuild logs.
Centralized audit logs are increasingly important for security and compliance. The workflow tracks interactions with Curation, its responses, and information from other JFrog services.
Teams do not have to search across multiple systems and domains to understand why a build failed. The JFrog and AWS integrations bring the relevant information together.
Agentic development needs this visibility because development speed is increasing dramatically. Businesses want more solutions, productivity, products, features, and capabilities, which places additional pressure on development teams.
Everything is accelerating, but security should not be left behind. Organizations should not introduce avoidable weaknesses into products delivered to their customers.
The solution shown today is an example of how such a development workflow can be implemented.
I want to emphasize that this is a demonstration solution developed jointly by AWS and JFrog.
The team is working through AWS and security approvals before publishing it through the AWS Samples GitHub organization. Once it is available, JFrog will also make it accessible to customers through its supporting materials.
Thank you.
Eldad Assis: Before we close, you can see my T-shirt: “Shift happens.”
We’re moving toward trusting AI agents to perform more work, but we must keep them under control with strict guardrails.
We demonstrated a workflow using Amazon Bedrock AgentCore and protected it with JFrog Curation.
There is a great deal of supporting information available, and the solution can help organizations protect agentic development workflows.
That is all for today. Thank you, Ken.
Ken Underhill: Thank you, Arik and Eldad.
That was an excellent look at what changes when AI agents become active participants in the software supply chain and how teams can balance increased speed with the governance required to operate safely.
We’ll now move into the Q&A portion. Please submit any questions through the Q&A tab.
Our first question is: Why would I use JFrog Curation instead of JFrog Xray?
Eldad Assis: Both JFrog Curation and JFrog Xray help protect organizations from vulnerabilities and malicious packages.
The key difference is that Curation blocks packages at the gate. As I mentioned earlier, it acts like a firewall. If a package violates policy, Curation prevents it from entering the organization.
Xray scans packages already stored in Artifactory. It can identify packages affected by vulnerabilities discovered after those packages were introduced and enforce the relevant policy.
You want a combination of both: scanning what you already have in Artifactory and protecting the organization from risky incoming packages. They complement each other.
Ken Underhill: Thank you. The next question is related: What happens if a vulnerability is discovered after a package has already been approved and deployed?
Eldad Assis: Xray has its own policies, which can be enforced across repositories.
It serves as a second line of defense because the package is already inside the organization when the new vulnerability is discovered.
A consumer may have successfully pulled the package yesterday but be blocked today because new vulnerability information causes it to violate policy.
That is the complementary role Xray provides.
Ken Underhill: The next question is about Curation itself. How long does a Curation evaluation take? Does it add latency to the build?
Arik Yakir: We tested the solution with and without Curation during development.
In our testing, Curation added a couple of milliseconds per package. Even with hundreds of packages, that represented only a few seconds.
The interaction among CodeBuild, Curation, and Amazon ECR adds some latency. However, when the complete build already takes several minutes, we considered those additional seconds acceptable and did not observe a meaningful drawback.
Eldad, would you like to add anything?
Eldad Assis: Curation performs a near-real-time validation using existing package intelligence.
If you add an on-demand Xray scan to the pipeline, that scan can take additional time. If the package was scanned previously, Xray may already have the metadata needed to identify a newly disclosed CVE.
That is another distinction between Curation and Xray.
Ken Underhill: From a security standpoint, can developers bypass the gate? For example, could they run pip install directly from PyPI?
Arik Yakir: Within the demonstrated workflow, the gate is built into the pipeline.
After the pre-build installation stage, the build runs through Curation. A developer cannot bypass it from within this governed CodeBuild path.
Someone might ask whether a developer could install a package directly from a laptop outside this AWS workflow. JFrog has announced additional capabilities designed to protect the broader organization, but that is a separate topic.
For the workflow demonstrated today, the security gate cannot be bypassed.
Ken Underhill: In the demonstration, you blocked packages with a CVSS score of nine or higher. Why not use a lower threshold? Isn’t seven or higher already considered high?
Eldad Assis: We support policies for different severity levels, and organizations can create custom policies.
We demonstrated a threshold of nine, but policies can apply to scores of seven or higher, eight or higher, or another threshold.
The correct threshold depends on your organization’s policy.
You can also activate policies in dry-run mode. The policy is not enforced, but potential violations are recorded.
You can then review the statistics and determine how many vulnerabilities with a CVSS score of seven or higher would have been identified without affecting current workloads.
The threshold of nine was only for the demonstration. Organizations can build policies around the CVSS scores they choose.
Ken Underhill: Our final question is: How does this work with transitive dependencies—the packages pulled by other packages?
Eldad Assis: Every package request is evaluated by Curation, regardless of whether it comes directly from the original project or is pulled as a transitive dependency.
If a transitive package violates policy, Curation blocks it and the workflow fails.
Ken Underhill: That is all the questions I see right now. If you have another question, please add it through the Q&A tab before we finish.
Thank you both.
Today’s session highlighted an important shift for development and platform teams. AI agents can remove friction from software delivery, but their value depends on the context, controls, and trusted access provided to them.
As agentic development becomes part of everyday workflows, the goal is not simply to make agents faster. It is to ensure that their speed operates within the security and governance expectations applied across the rest of the software supply chain.
If we cannot answer your question before the session ends, the JFrog and AWS teams can continue the conversation afterward.
Eldad, before we wrap up, how can attendees learn more about JFrog and continue exploring governed agentic development?
Eldad Assis: We have extensive information on our website. Visit JFrog.com for general information or JFrog.com/curation for information specifically about JFrog Curation.
Many of you may already be JFrog and AWS customers. The platforms work together, and you can use JFrog Curation and other security capabilities with your AWS workflows.
The information is available on our website.
Ken Underhill: Thank you again to both of you for joining us, and thank you to everyone who attended.
We’ll send the on-demand recording after the event, so please keep an eye on your inbox.
We look forward to seeing you at a future DZone webinar.
Arik Yakir: Thank you very much.
Presenters:
Arik Yakir
Senior Partner Solutions Architect, AWS
Eldad Assis
Principal DevOps Architect, CTO Office, JFrog
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
