Token IS transmitted by HM (confirmed); the agent didn't enforce it because AM
hadn't deployed the image containing the §5 check to production. So the debug
log is unnecessary — removed. Contract §0.1 updated: token-check is "code-ready,
pending AM prod image", not a HM gap. UI access-token/direct-URL display kept.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
AM shipped its updated runtime + fixes; live re-test confirms deploy → running
→ direct /health & /message/send (task completed) → stop → delete all pass, and
HM's per-agent access_token is minted + returned (non-empty UUID). Two AM-side
gaps remain: (1) the running agent does NOT enforce X-Agent-Access-Token
(no-token request still 200, agent card auth_required=None) — token isolation
not actually active; (2) subdomain is http:// (token + api_key in cleartext).
Contract §0.1 and client doc status notes updated accordingly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- AM contract: fix stale lifecycle path defaults in the env-override table
(/agents/{agent_id}, /agents/{agent_id}/stop — matches code, not the old
/api/agent/... values); correct the self-check create line to POST /agents;
align the verify-endpoint example to the real production response shape
(user_id is a string, agent_id included, miss returns {valid:false}).
- Client API: §0 overview now states HM mints the per-agent access_token
(AM no longer "returns" it).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per the chosen design, the agent authorizes callers by comparing the request
header X-Agent-Access-Token against its env AGENT_ACCESS_TOKEN (constant-time),
no HM round-trip. AM contract §3.1 now states ① as the agreed integration with
Python pseudo-code; the /agent-access/verify endpoint is demoted to an optional
fallback. Client API §6 spells out the client's job: send X-Agent-Access-Token
on every direct-connect request.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
HM now mints a random per-agent access token at deploy, injects it into the
agent env (AGENT_ACCESS_TOKEN + HEICODE_AGENT_ID) and returns it to the
deploying client (agent list access_token). Only the owning user receives it,
so only they can drive the agent — closing the gap where any valid sk- could
drive any agent and exfiltrate its mounted resources.
AM authorizes the caller either locally (compare to its env token) or via the
new public POST /api/heicode/agent-access/verify {agent_id, access_token} ->
{valid, user_id} (constant-time compare, no info leak on miss). AM may opt out.
Docs: AM contract §3.1 + client API §6 updated; access_token no longer empty.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- new §0.1 联调结果: real production test outcomes — create POST /agents works
(returns access_info.domain/namespace), DELETE /agents/{id} 500s (AM
UnboundLocalError bug), POST /agents/{id}/stop 404 (no endpoint), agent stays
Pending / subdomain unreachable. The 3 AM-side blockers listed up top.
- OPENAI_API_KEY is now injected (a minted user new-api sk-, billed to the user,
revoked on delete; verified working at /v1) — §1.1 env + §2 updated.
- §3 client<->agent: now documents AM's A2A protocol (message/send · stream),
api_key auth, and flags the per-user isolation security gap.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Preset templates carry a Claude-style frontmatter model (opus/sonnet) which is
NOT a model on the HM gateway. Passing it as MODEL_NAME would make the agent's
model calls fail. Now MODEL_NAME defaults to the gateway model gpt-5.4
(env AGENT_RUNTIME_DEFAULT_MODEL); a non-Claude-tier template model is honored.
Tests + AM contract doc updated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Real production test (user account) confirmed HM->AM POST /agents creates a real
agent (returned subdomain + status). But stop/delete still used the old
/api/agent/agents/{id} defaults and 404'd. Aligned status/stop/delete defaults to
the same namespace as create: /agents/{id}, /agents/{id}/stop. AM contract doc
notes these are HM's best guess pending AM's confirmation of the real lifecycle
endpoints (their doc only specified create).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adapt HM's template-agent integration to AM's actual CODING_A2A API (per their
doc), keeping it isolated in agent_template_runtime.go:
- start payload -> AM's POST /agents { name, template:"coding_a2a_agent",
framework:"A2A", config:{user_id,...}, env } with the template .md folded into
env.AGENT_INSTRUCTION_TEXT, template_key -> AGENT_ROLE_NAME, model gateway via
OPENAI_BASE_URL + MODEL_NAME (OPENAI_API_KEY left to the client per A2A request).
- response parse -> access_info.domain/external_ip -> subdomain, namespace/name
-> runtime_id; AM issues no access_token (client uses A2A api_key).
- env names aligned to AM: GIT_DEFAULT_BRANCH, POSTGRES_* (was PG_*),
AZURE_BLOB_ACCOUNT_NAME/CONTAINER/ACCOUNT_KEY (was BLOB_*); source keys aligned
to the resource-binding form (db_name/username/database_password/access_key).
Only AM-supported types (git/mysql/postgres/azure-blob); vm/redis/mongo/bucket
now rejected as unsupported until AM adds them.
- frontend: resources page splits DB into MySQL/PostgreSQL (correct provider),
drops vm; deploy page hides unsupported resource types.
- docs: AM contract + client doc updated to the real env names, payload, and the
A2A direct-connect (message/send · message/stream) + api_key auth.
- tests updated for the new env names + AM payload/response shape. All green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hand-off doc for the agent_management team: the 4 endpoints AM must implement
(start/status/stop/delete) with exact request/response (grounded in the isolated
adapter agent_template_runtime.go), the env naming convention AM templates must
read (git/vm/db/blob/bucket), AM's responsibilities (inject .env, validate the
agent access token, models via HM /v1/*, no secret leakage), the client<->agent
direct SSE contract AM needs to define, security requirements, the env-overridable
paths, and a joint integration checklist.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
chenchenandClaude Opus 4.8