Integrate Harness APIs - #680
Conversation
… interface (#682) * Create hosted-agent sessions from an agents.yaml manifest The harness-api backend provisions a session entirely from the agent spec, so replace the legacy JSON create(agent_kind=...) with create_from_manifest(), which uploads the manifest verbatim as Content-Type: application/x-yaml. The spec defines the runtime adapter, sandbox, env vars, and egress; there are no other arguments. - Add create_from_manifest() to the sync and async session clients, sharing manifest-normalization and YAML media-type helpers. - Remove the now-unsupported create(agent_kind=...) path. - Point the create_session.py example at a spec file and add session_e2e.py demonstrating the full create -> attach (send a prompt, stream SSE back) -> destroy flow. - Cover manifest upload in the sync and new async unit tests; drop the legacy create test. * regenerate fix * fix --------- Co-authored-by: SSharma-10 <shivanisharma@digitalocean.com>
Four standalone scripts exercising the permissions block:
- policy_auto_allow.py — touch * → allow runs without HITL
- policy_auto_deny.py — ls * → deny blocks without HITL prompt
- policy_hitl_ask.py — defaultAction: ask gates unmatched commands;
tests both approve and reject resolution paths
- policy_write_interception.py — Write/Edit (non-Bash) tool intercepted
under defaultAction: ask
All scripts load the base AGENT_SPEC, inject a permissions block, and
assert pass/fail without external YAML files.
![semgrep-code-digitalocean[bot]](https://avatars.githubusercontent.com/in/1159782?s=60&v=4){kind=small}
| for chunk in chunks: | ||
| yield chunk | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 82 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling / Uncontrolled Resource Consumption. aiohttp does not limit the number of HTTP header/trailer lines it parses. An attacker who controls a request (against an aiohttp server) or a response (against an aiohttp client) can send an unbounded number of trailer/header lines, causing uncapped memory consumption and denial of service. The vulnerable HTTP parser (HttpRequestParser/HttpResponseParser) is exercised by any aiohttp server accepting requests or any aiohttp client receiving responses, so there is no distinguishing code path to key on. Upgrade to aiohttp 3.13.4 or later.
To resolve this comment:
Upgrade this dependency to at least version 3.13.4 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| # Fallback for environments without the aio extra. | ||
| await _run_sync(_http_put_bytes, url, data) | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 61 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling / Uncontrolled Resource Consumption. aiohttp does not limit the number of HTTP header/trailer lines it parses. An attacker who controls a request (against an aiohttp server) or a response (against an aiohttp client) can send an unbounded number of trailer/header lines, causing uncapped memory consumption and denial of service. The vulnerable HTTP parser (HttpRequestParser/HttpResponseParser) is exercised by any aiohttp server accepting requests or any aiohttp client receiving responses, so there is no distinguishing code path to key on. Upgrade to aiohttp 3.13.4 or later.
To resolve this comment:
Upgrade this dependency to at least version 3.13.4 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| for chunk in chunks: | ||
| yield chunk | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 82 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling. The optimized C HTTP parser in aiohttp validates each fragment of an HTTP request/response line individually against max_line_size instead of the accumulated total. An attacker can split an oversized line across multiple network reads, bypassing the limit and causing excessive memory consumption, leading to denial of service. This affects both server-side request-target parsing and client-side response reason-phrase parsing.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.1 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| # Fallback for environments without the aio extra. | ||
| await _run_sync(_http_put_bytes, url, data) | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 61 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling. The optimized C HTTP parser in aiohttp validates each fragment of an HTTP request/response line individually against max_line_size instead of the accumulated total. An attacker can split an oversized line across multiple network reads, bypassing the limit and causing excessive memory consumption, leading to denial of service. This affects both server-side request-target parsing and client-side response reason-phrase parsing.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.1 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
Bring Action Gateway Private Preview (PR #694) onto OHS_endpoints, keeping both hosted agents and gateway client wiring. Co-authored-by: Cursor <cursoragent@cursor.com>
4 participants
No description provided.