Skip to content

[Amazon Bedrock AgentCore]: Integration Enhancement - Add Code Interpreter and Runtime Command datasets #19936

New issue
New issue
Open
#22209
Open
[Amazon Bedrock AgentCore]: Integration Enhancement - Add Code Interpreter and Runtime Command datasets#19936
#22209
Assignees
moxarth-rathodmiguel-sanchez-elastic
Labels
Integration:aws_bedrock_agentcoreAmazon Bedrock AgentCoreTeam:SDE-CrestCrest developers on the Security Integrations team [elastic/sit-crest-contractors]Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]

Description

@bryans3c
bryans3c
opened on Jul 2, 2026

Integration Name

Amazon Bedrock AgentCore [packages/aws_bedrock_agentcore]

Dataset Name

code_interpreter_application_logs, runtime_command_logs, runtime_application_logs

Integration Version

0.7.0

Agent Version

9.4.2

OS Version and Architecture

Elastic Agent on Amazon Linux (EC2)

User Goal

I'm building detection rules for the AgentCore privilege-escalation paths in BeyondTrust's research
(https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation). The core technique: code or commands executed inside an AgentCore runtime or code interpreter read the execution-role credentials from the instance-metadata endpoint (169.254.169.254) and use them outside the resource.

I confirmed the exploit end-to-end in our AWS lab — the stolen credentials authenticate as the resource's execution role via sts:GetCallerIdentity. I want to detect this behavior using the telemetry the AgentCore integration provides.

Existing Features

0.7.0 exposes runtime_application_logs, gateway_application_logs, memory_application_logs, and metrics.

But runtime_application_logs only carries the OTel InvokeAgentRuntime prompt records
(request_payload.prompt), the agent-invocation path. The actual exploit steps never reach any dataset:

  • Code Interpreter (InvokeCodeInterpreter): no dataset exists, even though it emits a structured APPLICATION_LOGS record (same delivery mechanism as runtime_application_logs) containing the executed code and its returned output.
  • Runtime command exec (InvokeAgentRuntimeCommand): emits no OTel record and the command lands only as raw stdout in the runtime -DEFAULT [runtime-logs] streams, which the vended APPLICATION_LOGS delivery does not carry.

So no field in any current dataset carries the executed code/command or its output, which is exactly where
the credential-harvesting behavior appears. With no data, there's no detection to write.

What did you see?

Nothing arrives at Elastic regarding the specific techniques.

Anything else?

No response

Activity

  1. bryans3c
    added
    needs:triage
    on Jul 2, 2026

  2. github-actions commented on Jul 2, 2026

    @github-actions
    github-actionsBot
    on Jul 2, 2026 – with GitHub Actions
    Contributor

    tl;dr: This is a valid enhancement request: aws_bedrock_agentcore has Code Interpreter metrics but no Code Interpreter application-log dataset, and its existing runtime log dataset is specific to InvokeAgentRuntime, so it will not capture the executed code/command/output needed for these detections.

    Recommendation

    Add two new log data streams to packages/aws_bedrock_agentcore:

    1. code_interpreter_application_logs for the structured vended APPLICATION_LOGS records emitted by InvokeCodeInterpreter.
    2. runtime_command_logs for raw runtime command/stdout records from the runtime -DEFAULT [runtime-logs] CloudWatch streams.

    Do not extend runtime_application_logs alone. Its pipeline currently assumes the Agent Runtime invoke shape and hard-codes the normalized operation to invoke_agent, which would either misclassify or drop Code Interpreter/command-specific content.

    Findings

    Current package state:

    • packages/aws_bedrock_agentcore/manifest.yml:4 is version 0.7.0.
    • packages/aws_bedrock_agentcore/manifest.yml:7 says the package covers Agent runtime, Gateway, Identity, Memory, Browser Tools, and Code Interpreter metrics/logs.
    • packages/aws_bedrock_agentcore/docs/README.md:20-21 documents only the metrics data stream in the top-level data-stream list, while the Logs section starts with Runtime Application Logs at packages/aws_bedrock_agentcore/docs/README.md:281-289.
    • Existing data streams on disk are only gateway_application_logs, memory_application_logs, metrics, and runtime_application_logs.
    • Code Interpreter is present in metrics/dashboards: packages/aws_bedrock_agentcore/data_stream/metrics/manifest.yml:1-6 defines the metrics stream, and the dashboard references InvokeCodeInterpreter, but there is no code_interpreter_application_logs data stream.

    Why runtime_application_logs is not enough:

    • packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/manifest.yml:1-3 defines only aws_bedrock_agentcore.runtime_application_logs.
    • The runtime pipeline parses JSON into aws.bedrock_agentcore at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:19-25.
    • It copies/flattens only body.request_payload and body.response_payload at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:80-98.
    • It removes the remaining body at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:101-104, so non-modeled body fields from another structured log shape would not be preserved unless the pipeline is changed.
    • It hard-codes aws.bedrock_agentcore.operation_name to invoke_agent at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:142-145.
    • Runtime fields model prompt/request/response payloads, not code/command output: packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/fields/fields.yml:45-62.
    • The pipeline test fixture is an InvokeAgentRuntime record with body.request_payload.prompt: packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/_dev/test/pipeline/test-aws-bedrock-agentcore.log:1.
    • The sample output confirms the normalized dataset and operation are runtime-specific: packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/sample_event.json:54-68.

    Relevant prior package work:

    Verification

    I verified the package data streams and searched for the requested dataset/operation names:

    $ cd /home/runner/work/integrations/integrations
$ find packages/aws_bedrock_agentcore/data_stream -maxdepth 1 -mindepth 1 -type d -printf '%f\n' | sort
gateway_application_logs
memory_application_logs
metrics
runtime_application_logs

$ grep -RInE 'InvokeCodeInterpreter|InvokeAgentRuntimeCommand|code_interpreter_application_logs|runtime_command_logs' packages/aws_bedrock_agentcore || true
packages/aws_bedrock_agentcore/kibana/dashboard/aws_bedrock_agentcore-5e628ac1-5bd8-48f1-acad-5a940483b81a.json:111:                                "InvokeCodeInterpreter",
packages/aws_bedrock_agentcore/kibana/alerting_rule_template/aws-bedrock-agentcore-code-interpreter-errors.json:16: ... InvokeCodeInterpreter ...
packages/aws_bedrock_agentcore/kibana/alerting_rule_template/aws-bedrock-agentcore-code-interpreter-high-latency.json:16: ... InvokeCodeInterpreter ...
packages/aws_bedrock_agentcore/kibana/alerting_rule_template/aws-bedrock-agentcore-code-interpreter-throttles.json:16: ... InvokeCodeInterpreter ...

    elastic-package is not installed in this workflow environment, so I could not run package pipeline tests here:

    $ command -v elastic-package || true
# no output
    Detailed Action Plan

    1. Add packages/aws_bedrock_agentcore/data_stream/code_interpreter_application_logs/ by following the existing log data-stream layout from runtime_application_logs, gateway_application_logs, and memory_application_logs:

      • manifest.yml with dataset aws_bedrock_agentcore.code_interpreter_application_logs and both aws-cloudwatch and aws-s3 stream templates.
      • agent/stream/aws-cloudwatch.yml.hbs and agent/stream/aws-s3.yml.hbs, likely copied from runtime_application_logs unless Code Interpreter needs different default log-group guidance.
      • elasticsearch/ingest_pipeline/default.yml that parses the structured APPLICATION_LOGS JSON but sets an operation such as invoke_code_interpreter only when appropriate, rather than hard-coding invoke_agent.
      • fields/fields.yml for Code Interpreter identifiers and payload fields, including executed code/input and returned output/result fields based on real AWS sample payloads.
      • _dev/test/pipeline/*.log and *-expected.json fixtures covering at least code input, output, error output, request/session/resource identifiers, and large payload behavior.

    2. Add packages/aws_bedrock_agentcore/data_stream/runtime_command_logs/ for raw runtime command logs:

      • Use the same AWS CloudWatch/S3 collection pattern, but configure docs and tests around runtime -DEFAULT [runtime-logs] streams instead of vended APPLICATION_LOGS streams.
      • Preserve event.original/message and map command execution content to fields useful for detections, for example command line, stdout, stderr, exit status if present, session/request/resource identifiers when extractable, cloud.account.id, cloud.region, and log.file.path/CloudWatch stream metadata.
      • Avoid lossy parsing: if command stdout is unstructured, keep the raw line searchable and only extract fields when the format is deterministic.

    3. Update package docs and metadata:

      • Update packages/aws_bedrock_agentcore/docs/README.md:20-21 to list log data streams, not only metrics.
      • Add setup guidance near packages/aws_bedrock_agentcore/docs/README.md:38-47 for selecting the Code Interpreter APPLICATION_LOGS log group and runtime command log streams.
      • Add examples to the Logs section after packages/aws_bedrock_agentcore/docs/README.md:281-289 for the two new datasets.
      • Add a new top entry in packages/aws_bedrock_agentcore/changelog.yml for the enhancement.

    4. Validate locally with package tests once implemented:

    cd packages/aws_bedrock_agentcore
elastic-package test pipeline --data-streams code_interpreter_application_logs,runtime_command_logs,runtime_application_logs
elastic-package build
    Related Items
    Type Item Relevance
    Issue #19936 Request to add Code Interpreter and runtime command telemetry for detection coverage.
    PR #15991 Added the existing runtime_application_logs data stream referenced by this issue.
    PR #16577 Added Code Interpreter metrics/dashboard support, but not Code Interpreter application logs.
    PR #16587 Added gateway_application_logs; useful as a recent log data-stream implementation pattern.
    PR #16588 Added memory_application_logs; useful as a recent log data-stream implementation pattern.
    File packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:80-104 Current runtime pipeline only preserves modeled request/response payloads and removes remaining body.
    File packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:142-145 Current runtime pipeline hard-codes operation_name: invoke_agent.
    File packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/fields/fields.yml:45-62 Current runtime fields model prompt/request/response payloads only.
    File packages/aws_bedrock_agentcore/docs/README.md:281-289 Current Logs documentation starts with only Runtime Application Logs.

    What is this? | From workflow: Issue Triage

    Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

  3. andrewkroh
    added
    Integration:aws_bedrock_agentcoreAmazon Bedrock AgentCore
    Team:Obs-InfraObsObservability Infrastructure Monitoring team [elastic/obs-infraobs-integrations]
    on Jul 2, 2026

  4. narph commented on Aug 10, 2026

    @narph
    narph
    on Aug 10, 2026
    Contributor

    @elastic/obs-infraobs-integrations , @ishleenk17 can you folks chime in here?

  5. ishleenk17 commented on Aug 10, 2026

    @ishleenk17
    ishleenk17
    on Aug 10, 2026
    Member
    • It copies/flattens only body.request_payload and body.response_payload at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:80-98.
    • It removes the remaining body at packages/aws_bedrock_agentcore/data_stream/runtime_application_logs/elasticsearch/ingest_pipeline/default.yml:101-104, so non-modeled body fields from another structured log shape would not be preserved unless the pipeline is changed.

    So, is the main requirement that we want other fields parsed/mapped from the body as well before dropping it ?

  6. agithomas commented on Aug 11, 2026

    @agithomas
    agithomas
    on Aug 11, 2026
    Contributor

    Thanks @bryans3c, for creating this Enhancement request. Yes, this is a known gap from when we developed the Amazon Bedrock AgentCore integration.

    ++ @emma-raffenne for tracking and prioritisation of the request.

  7. bryans3c commented on Aug 31, 2026

    @bryans3c
    bryans3c
    on Aug 31, 2026
    ContributorAuthor

    Hi @agithomas @emma-raffenne, any update on this? Thanks!

  8. emma-raffenne commented on Sep 26, 2026

    @emma-raffenne
    emma-raffenne
    on Sep 26, 2026
    Contributor

    @elastic/obs-signals-traces-team I believe this is on your team (LLM observability)

  9. jennypavlova commented on Sep 28, 2026

    @jennypavlova
    jennypavlova
    on Sep 28, 2026
    Member

    I believe it should be @elastic/obs-signals-ai-o11y?

  10. emma-raffenne
    removed
    Team:Obs-InfraObsObservability Infrastructure Monitoring team [elastic/obs-infraobs-integrations]
    on Sep 30, 2026

  11. bryans3c commented on Oct 1, 2026

    @bryans3c
    bryans3c
    on Oct 1, 2026
    ContributorAuthor

    Hi @agithomas @emma-raffenne, any update on this? Thanks!

  12. agithomas commented on Oct 1, 2026

    @agithomas
    agithomas
    on Oct 1, 2026
    Contributor

    Hi @agithomas @emma-raffenne, any update on this? Thanks!

    @bryans3c , the Obs-signals-integration team no longer owns this enhancement request (ER).

    @hegerchr , could you please take a look and have someone from your team take it forward?

  13. hegerchr
    assigned
    miguel-sanchez-elastic
    on Oct 5, 2026

  14. hegerchr commented on Oct 5, 2026

    @hegerchr
    hegerchr
    on Oct 5, 2026

    @miguel-sanchez-elastic is the PM and will review the ER. My understanding is that this is not a CVE or security incident. It's an ER to collect additional data with the integration.

  15. Mikaayenson
    added a parent issue on Oct 5, 2026

  16. miguel-sanchez-elastic commented on Oct 6, 2026

    @miguel-sanchez-elastic
    miguel-sanchez-elastic
    on Oct 6, 2026
    Contributor

    Hi @bryans3c and @narph ,

    I am the (new) PM of the area and I am getting familiar with this. Would you mind sharing who is the PM in your area? I'd like to talk with them to understand more about the need and urgency

    Hi @agithomas , do you remember why we knew about this gap and we didn't do it? Was it to cut scope? complexity? other?

  17. bryans3c commented on Oct 6, 2026

    @bryans3c
    bryans3c
    on Oct 6, 2026
    ContributorAuthor

    Hi @miguel-sanchez-elastic,

    I'm adding @Mikaayenson to the thread. We need those new datasets to expand coverage for Amazon Bedrock AgentCore, you have one link based on BeyondTrust research that we can't cover now with the current datasets.

    Thanks!

  18. jamiehynds
    added
    Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]
    on Oct 9, 2026

  19. infra-vault-gh-plugin-prod commented on Oct 9, 2026

    @infra-vault-gh-plugin-prod
    infra-vault-gh-plugin-prodBot
    on Oct 9, 2026

    Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

  20. jamiehynds
    added
    Team:SDE-CrestCrest developers on the Security Integrations team [elastic/sit-crest-contractors]
    and removed
    needs:triage
    Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]
    on Oct 9, 2026

  21. agithomas commented on Oct 9, 2026

    @agithomas
    agithomas
    on Oct 9, 2026
    Contributor

    Hi @agithomas , do you remember why we knew about this gap and we didn't do it? Was it to cut scope? complexity? other?

    Correct, it was to cut the scope.

  22. kcreddy commented on Oct 14, 2026

    @kcreddy
    kcreddy
    on Oct 14, 2026
    Contributor

    But runtime_application_logs only carries the OTel InvokeAgentRuntime prompt records
    (request_payload.prompt), the agent-invocation path. The actual exploit steps never reach any dataset:

    Code Interpreter (InvokeCodeInterpreter): no dataset exists, even though it emits a structured APPLICATION_LOGS record (same delivery mechanism as runtime_application_logs) containing the executed code and its returned output.
    Runtime command exec (InvokeAgentRuntimeCommand): emits no OTel record and the command lands only as raw stdout in the runtime -DEFAULT [runtime-logs] streams, which the vended APPLICATION_LOGS delivery does not carry.

    The implementation will need two new data streams, one for each log type: code_interpreter_application_logs for the InvokeCodeInterpreter vended APPLICATION_LOGS records, and a runtime_logs/runtime_container_logs data stream for the -DEFAULT [runtime-logs] streams that carry the InvokeAgentRuntimeCommand output.

    cc: @narph

  23. narph
    added
    Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]
    on Oct 20, 2026
  24. kcreddy
    assigned
    moxarth-rathod
    on Oct 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Integration:aws_bedrock_agentcoreAmazon Bedrock AgentCoreTeam:SDE-CrestCrest developers on the Security Integrations team [elastic/sit-crest-contractors]Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions