When The Shared Responsibility Model Comes to the Harness was published in May, the Coalition for Secure AI’s own appendix recorded AWS as having no published shared-responsibility model for AI.
That was accurate then. It is not accurate now.
AgentCore harness reached general availability on June 18, 2026, reducing an agent deployment to a definition call and an invocation call [1]. Shipped alongside it is a security and access controls page that states, in operational language, which properties of an incoming request the platform validates and which it does not [2]. That page is the harness-layer responsibility statement the matrix was drawn without. It is also the most useful document AWS publishes about this product, and it is not the one most architects will read first.
Its central sentence is that the harness validates the structure of a request but does not inspect its meaning [2]. Everything in this dispatch follows from that.
Five Bands, Two Held Jointly
The prologue argued that the published boundary is not a straight line. AgentCore is where that is easiest to demonstrate. The platform holds the orchestration loop outright — the managed harness runtime is what a customer is buying instead of writing. The platform also holds microVM isolation and the infrastructure beneath it. But the sandbox band is jointly held, because isolation of the environment and the safety of commands executed inside it are different obligations resting with different parties [2]. The tools band is jointly held for the same reason: the platform supplies the gate, the customer decides which tools exist and what they can reach.
Note where the top two bands land. Both sit with the customer. An architect reading the capability sheet sees a managed harness and reasonably infers a managed perimeter. The responsibility page says otherwise: authorization of callers and validation of their input are customer obligations [2].
Where Does the Session Record Reside?
With the customer, on all three surfaces, and this is the platform’s strongest property.
Sessions execute in the customer’s own account under an execution role the harness assumes, declared as a role identifier on the harness itself [5]. Managed memory arrives as an addressable customer-owned resource with semantic and summarization strategies, a thirty-day event expiry, and namespace isolation per actor — not as an opaque platform-side store [1]. Traces, logs, and metrics land in CloudWatch through that same execution role, with a harness view that drills from harness to session to individual trace [1].
For a regulated workload this is the answer that makes the rest of the conversation possible. The processor arrangement puts the customer on both sides of it: retention schedule, legal hold, and discoverability are all properties the customer sets, because the artifacts are in the customer’s account. AWS states AgentCore’s compliance program eligibility at the service level — HIPAA eligible, FedRAMP Class C, SOC 2, ISO, and CSA STAR, with a further list internally assessed and pending third-party audit in coming cycles [4]. Two qualifications travel with that: it is stated for the service, not scoped to the harness specifically, and the second list is self-assessment rather than completed audit. Both are stated by AWS, and both belong in a compliance review rather than in a slide.
What Is the Hard Limit Denominated In?
Iterations, seconds, and tokens. Not currency.
Five caps are available, all optional. Reasoning iterations default to seventy-five. A single invocation times out at thirty-six hundred seconds. A token budget bounds total output. An idle microVM stays warm for nine hundred seconds. Total session lifetime tops out at twenty-eight thousand eight hundred seconds [3]. Each is settable on the harness and overridable on a single invocation [3][5][6]. When one binds, it surfaces as a named stop reason — iterations exceeded, timeout exceeded, output tokens exhausted — which is the correct design: a bounded run terminates with a reason a caller can branch on [8].
Two properties of that set matter at specification time.
The scope is the invocation, not the session. The API reference is explicit: iterations, tokens, and duration each bound a single invocation [5]. A session composed of many invocations is bounded by the product of its parts, and that product is not itself a declared ceiling.
The unit is resources, not money. AWS is direct about the consequence and does not leave it to inference: observability explains activity but is not a billing report, and billed usage belongs to Cost Explorer or the Cost and Usage Report [3]. Cost attribution is a tagging discipline — harness tags propagate to the managed Runtime, its endpoint, and managed Memory, while Gateway, EFS, S3, and a bring-your-own Memory resource must be tagged independently [3]. That is a competent attribution story. It is a reporting instrument rather than a preventive one, and a token ceiling does not become a spend ceiling when the provider serving a step can change between invocations [6].
Where Is the Tool Gate Declared?
In two places, and the second one is the platform’s quietest strength.
Policy is declared. AgentCore Policy evaluates calls at the Gateway boundary against rules naming who may call which tool, under which conditions, and with which arguments [2]. That is a reviewable authorization artifact, not a convention — a reviewer can read it and a release process can diff it. The harness adds a server-side control of its own: a caller cannot name a tool in a final message and have it dispatched, and AWS notes that non-harness Runtime offers no equivalent server-side protection [2]. Choosing the harness buys that check.
Change control is where AgentCore separates from most managed agent surfaces.
Every update mints an immutable version, and named endpoints stay pinned to a chosen version until promoted [1]. The update operation accepts the full definition — model, tools, skills, system prompt, execution role, limits, and truncation strategy — so a version is a complete snapshot of what produced a run rather than a delta against something mutable [7]. Promotion repoints an endpoint forward; rollback repoints it back; nothing is rewritten. For an assurance program that is the difference between an assertion and an artifact — a minted version is a thing an auditor can name and a release process can pin, and the configuration that produced a given trace remains retrievable after the next deployment.
What the Customer Owes
The trust boundary is an identity check. A principal that passes it reaches the session sandbox, every configured tool, the skill sources in effect, and the provider configuration [2]. Authentication answers who is calling. It does not answer whether this caller should reach this tool with these arguments, and AWS assigns caller authorization and input validation to the customer explicitly [2].
Three obligations follow, all of them documented by AWS rather than discovered.
Provider parameters pass through to the provider unchanged; the harness does not validate, filter, or restrict them [2]. That is precisely what makes provider choice available — the same field that lets an architect route to Bedrock, to a direct provider, or through a proxy layer, and change that routing between invocations, is a field the platform does not interpret. AWS documents what a caller able to set it can do: redirect requests to a different endpoint, override authorization headers, attempt role assumption, or substitute model and region [2]. So the obligation is symmetric with the capability. Restrict who can set those parameters, validate them before forwarding, and review overrides as configuration changes rather than as request data.
Skills are trusted input. The harness does not inspect or sanitize skill content, and skills are overridable per invocation, as are tools, system prompt, model, and the allowed-tools filter [2][6]. An agent’s instructions are therefore part of its request surface. Skill provenance belongs under the same change control as code.
Identity propagation depends on the authentication path. Under signature-based authentication the harness does not carry per-user identity into downstream tool calls; per-user credential scoping through the token vault is available on the bearer-token path [2]. An architecture that needs a tool call attributable to an end user has to choose the path that supports it.
AgentCore harness gives the customer the session record, the trace, and an immutable version history — the three things an assurance program is hardest pressed to reconstruct after the fact. It also gives the customer the model field, the skill sources, and caller authorization, and AWS says so on the page that describes them.
Model choice is a customer control in both senses. It is a lever the customer holds, and it is a control the customer operates. The platform published which one it validates. Whether the other is validated is an architectural decision, made at design time, on the write path.
Next in the arc: the Claude Architect dispatch reads Managed Agents against the same three questions, where the session record answers differently and the hard limit is denominated in currency.
