On Java, an IAST sensor is typically packaged as an agent JAR that the JVM loads at startup through the javaagent option. The agent rewrites method bytecode as classes load, so it can watch data move through the running app without any change to your source code.
What the JVM actually provides
Java ships a standard package, java.lang.instrument, that lets agents instrument programs running on the JVM. Per Oracle's documentation, instrumentation works by modifying the bytecode of methods, either as classes are loaded or on classes that are already loaded. An agent is a JAR file whose manifest names the agent class.
OWASP describes IAST sensors as software libraries included in the application, which monitor behavior while tests run and raise an alert when they detect a vulnerability. On the JVM, the agent mechanism is the common way to get those sensors in place. Individual products may differ, so confirm the attach method with any vendor.
Three ways an agent can start
| Method | When it runs | If it fails |
|---|---|---|
| Command line javaagent option | Before the application main method | The JVM aborts |
| Attach to a running JVM | After the VM has started | The error is ignored, the app keeps running |
| Launcher agent attribute in an executable JAR | Before main | The JVM aborts |
The table comes straight from the Oracle package documentation. The difference matters. A startup agent that cannot load will stop your service from booting, which is loud and safe. A late attach can fail quietly, which means your test run may produce no findings simply because nothing was watching.
What this means for your pipeline
Pick the attach method deliberately.
- Use the startup option in test and QA containers, so a broken agent fails the deploy instead of hiding.
- Add a smoke check that proves the agent is alive, such as a known test finding or a heartbeat in the vendor console.
- Keep the agent version pinned and updated through the same process as any other dependency.
- Record the exact JVM flags in the container definition so every environment starts the same way.
Treat the agent as privileged code
Oracle's documentation says agent JARs can do anything an application can do, including creating threads, and that whoever deploys an agent is responsible for verifying it is trustworthy, since agents can change how code runs. That is a supply chain question as much as a testing one. Ask where the agent is built, how it is signed, how updates reach you, and what data it sends out.
The same mechanism powers observability. The OpenTelemetry Java agent, for example, attaches to a Java 8 or later application and modifies bytecode at runtime to capture telemetry without code changes. If you already run an agent like that, you know the operational shape: one more JAR, one more startup flag, one more thing to keep current.
A worked example: baking the agent into a test image
Imagine a team with a Java service that already builds a container image for its integration tests. The simplest path is to add the agent JAR to a dedicated test image, not the production one, and set the javaagent option in the image's start command. Because the flag lives in the image definition, every engineer and every CI run starts the service the same way. If the JAR is missing or corrupt, the JVM aborts at startup and the pipeline fails at the deploy step, which is a loud and useful signal.
Now consider the alternative. Another team attaches an agent to an already running test instance from a script. That works, but per Oracle's documentation a failure in that mode is ignored rather than fatal. The script exits cleanly, the integration tests run, and the report is empty. Nothing looked wrong. This is the classic way a pipeline reports zero findings because nothing was watching.
A checklist before you trust the first report
Run through these checks on the first run in any new environment.
- Confirm the agent version in the vendor console matches the version you intended to deploy.
- Trigger a known test condition, such as a deliberately unsafe sample endpoint in a sandbox application, and confirm it appears.
- Check the application log at startup for agent messages. The JVM may log agent problems even when it does not abort.
- Compare startup time with and without the agent, so you know the agent is actually doing work.
- Confirm that the agent reports from every instance, not only the first one, if you run several replicas.
- Save the exact command line used to start the service in your build record.
These six checks take under an hour and prevent weeks of false comfort.
Where agent attachment gets complicated
Real deployments add wrinkles. Build tools may wrap the java command in a script, so the flag has to be injected through an environment variable the script respects. Some platforms start the process for you, which means the option must be set in platform configuration. Several agents can run side by side, and Oracle notes that multiple javaagent options are allowed and that their premain methods run in command line order. Order can matter when two agents rewrite the same classes, so keep the list short and test combinations.
Containers add another point: the JVM version in the image must support what the agent needs. Pin the base image and re-run your smoke test whenever it changes.
Agent attachment and your supply chain
The agent JAR is a build input like any other. Store it in your artifact repository, record its checksum, and refuse to start images that contain an unexpected version. That gives you a record of what was running during each test, which also helps later if a reviewer asks how a result was produced.
Summary
Attach at startup in test environments so failures are loud. Verify the agent with a known test condition. Pin the version and treat the JAR as a privileged dependency. Remember that a late attach can fail quietly. Record the exact launch flags. With these habits the agent is dependable, and your reports mean what you think they mean.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an image is broken into layers and components. An agent JAR you bake into a test image appears in that same kind of inventory, which is why it belongs in your records.
Quick check
Do I need to change my source code to use an IAST agent?
Generally no. The agent instruments bytecode at load time. You do change your launch configuration, and you still need tests or traffic to exercise the code.
Can I attach an agent to a JVM that is already running?
Yes, the Java instrument API allows it, with an agent class started after the VM is up. A failure there is ignored rather than fatal, so verify the agent actually loaded.
Is the agent itself a security risk?
It can be. It runs with the full power of your application, so vet its provenance and update path like any privileged dependency.
For the wider picture, read what IAST is and what IAST needs to work. If you want to see what is inside your own dependency tree, Safeguard offers a free scan at gold.safeguard.sh/scan with SBOM and dependency scanning.
Sources
- Oracle: java.lang.instrument package
- OWASP DevSecOps Guideline: Interactive Application Security Testing
- OpenTelemetry: Java zero-code instrumentation agent
Last reviewed: 19 October 2026.
