Giving an agent a tool is easy to demonstrate and hard to operate safely. A model may decide to look up a service ticket, retrieve account context, or propose a change, but neither the model’s confidence nor the shape of its request proves that the action is authorized. In a production AgentCore system, the important boundaries are who invoked the agent, which tools it may discover, what identity reaches each target, and which business operations remain under deterministic controls.
Imagine a fictional equipment-support assistant that investigates service tickets. It may search equipment history and prepare a proposed resolution. Closing a ticket or changing an entitlement, however, must still require approved business conditions. An engineering team can use a development framework, a managed agent runtime, a gateway and existing APIs to build this experience, but those layers must not be collapsed into one vaguely defined “agent permission.”
AWS positions Amazon Bedrock AgentCore as building blocks for running and connecting agent workloads. Strands Agents is a framework that can develop the agent’s reasoning and tool-use behavior; AgentCore Runtime may host the running agent; AgentCore Gateway exposes supported targets through tool interfaces. Each provides useful capabilities, while the application and backend still own the business authorization decisions.
Separate agent reasoning from execution infrastructure
An agent loop interprets a request, invokes an allowed tool and integrates its result; a state machine instead executes declared transitions and retry policies. AgentCore and AWS Step Functions can therefore serve complementary roles: model-driven selection of information or recommendations, followed by deterministic validation, authorization and execution. For a warranty exception, record whether the requested refund was approved before allowing a state transition that commits it.
AgentCore components should be selected for their actual responsibility. Runtime hosts agent code and manages its invocation environment, Gateway presents external tools and APIs through supported MCP interfaces, and Identity assists with managed credential-related workflows. The AWS service can help authenticate configured connections, but no component reads an organization’s entire authorization policy from the business meaning of a free-form user request. An access boundary not explicitly implemented remains a gap.
For new greenfield work, note the service lifecycle. AWS states that Amazon Bedrock Agents Classic stopped accepting new customers on July 30, 2026 and points new agentic workloads toward AgentCore. That does not mean Knowledge Bases, Guardrails or every Bedrock service entered maintenance. It also does not make code written against Agents Classic identical to AgentCore Gateway or Strands examples. Verify the exact target product when adapting an implementation.
Design the tool contract around a narrow capability
Start with a read-only capability such as getTicketHistory(ticketId), with clearly specified input type, validation rules and output fields. A useful output includes the requested ticket identity, a bounded summary, evidence identifiers and an explicit not-found or access-denied status. It should not return unrelated customer records, raw credentials or every hidden attribute merely because the model might find them interesting. Tool output is untrusted application data, not a new developer instruction.
When writing is necessary, separate proposeTicketUpdate from applyTicketUpdate. The first operation can produce a preview of the intended change, affected fields and reason. The second should require a validated caller identity, an approved ticket scope, an authorization decision, an expected record version and any required human approval. Its API should reject stale preconditions and report whether the action actually committed. Exposing one unrestricted executeArbitraryRequest tool defeats the purpose of a bounded interface.
Include failure semantics in the schema. Invalid arguments are validation errors; an unknown ticket is not found; an inaccessible ticket is denied; a temporary dependency outage is retryable only according to a documented policy. The agent should not be trained to interpret every error as a reason to modify parameters and try again. Repeatedly probing other ticket IDs after an authorization failure is not an acceptable recovery strategy.
Understand Gateway inbound and outbound authorization
An AgentCore Gateway has an inbound authentication and authorization configuration, but the chosen mode determines where enforcement occurs. With offloaded or no-authorization modes, the gateway does not independently establish a caller’s business permissions; a policy engine, interceptor or backend must enforce them. Outbound authorization determines how the gateway authenticates to a particular target. AWS describes gateway service-role signing, target-supported caller IAM credentials, OAuth flows and API keys in AgentCore Gateway outbound authorization. Check the actual target type before choosing a flow; a credential method supported by an HTTP target is not automatically supported by an MCP or Lambda target.
Consider a gateway that uses one IAM service role to reach several backend resources. Those targets may see the gateway’s role instead of the actual employee’s permissions. A broad role can become an unintended privilege amplifier unless the application also authorizes each request by the verified user and ticket scope. AWS recommends least privilege for gateway execution roles and separate gateways across materially different trust boundaries when appropriate. It also provides policy mechanisms to limit which callers can invoke which targets.
Delegated OAuth is different from client-credential access: the latter identifies an application, while the former can convey permissions granted in a user context. For supported HTTP targets, JWT passthrough forwards the incoming bearer token and leaves the target responsible for validating its issuer, audience, scopes and caller context. It is not a universal MCP tool permission; check the deployed gateway’s inbound mode and target compatibility in the versioned service documentation. Where supported, an on-behalf-of token exchange can provide a separate token scoped to the downstream resource rather than reuse the inbound token. The backend must never accept a user identifier supplied by the model as proof of authority to edit a ticket.
Make MCP discovery a capability boundary
Model Context Protocol lets agent clients discover and invoke tools through standardized descriptions and arguments. In an AgentCore Gateway deployment, configured targets become available through MCP-compatible interfaces. Tool descriptions help the agent select an operation, but they do not replace the Gateway’s access configuration or backend validation. A tool saying “only use for authorized customers” is still a string that a model may misinterpret.
Use distinct gateways or tool sets for read-only inquiry and consequential actions when that separation reduces blast radius. If a technician may inspect service logs but not approve payment changes, the write capability should not simply sit next to read-only tools waiting for a better prompt. Enforce allowlists, tenant scoping and capability restrictions at the service boundary; keep tool metadata accurate and avoid ambiguous names that could cause an agent to choose a write operation when it intended to retrieve data.
Protocol and SDK features evolve. A connection pattern that requires initialization and retained sessions in one MCP version may differ from a newer stateless interaction. Confirm the supported protocol revision and client expectations for the deployed Gateway and runtime, particularly when migrating older tool examples. Do not infer that any generic HTTP endpoint becomes a secure MCP target merely by copying a JSON schema around it.
Contain untrusted tool results and prompt injection
A service ticket can include an instruction to export unrelated records, but its text is evidence, not authority. Bedrock Guardrails and prompt-injection defense can help classify or reject some malicious prompt content; the decisive control is that the backend tool identity cannot read or write outside the caller’s allowed case. Test both layers with a synthetic ticket: even if the model follows a hostile instruction, an unauthorized API operation must fail independently.
Tool response validation must be symmetric with argument validation. Normalize expected fields, bound the volume of returned data, reject executable markup where inappropriate and label unverified external content. A legitimate lookup can fail or return contradictory records; the agent should surface uncertainty or escalate rather than silently using unrelated data as a replacement. Avoid logging access tokens or private documents while investigating a tool call; use request and evidence identifiers wherever possible.
Human approval should be meaningful. The approver needs to see the proposed change, the source evidence, the affected account or ticket and the difference from current state. An empty “Approve” button following an opaque agent recommendation is a weak control. After approval, deterministic backend code should repeat the authorization and precondition checks at the moment of execution, because both user permissions and ticket state may have changed.
Engineer retries and idempotency around business effects
A tool call may succeed on the backend even if the network connection fails before the agent receives the response. Retrying that call blindly can issue a second refund, close a ticket twice or send duplicate notifications. For consequential operations, use idempotency keys and a durable action ledger keyed to a business request, not just a transient model turn. Return a stable result for a verified retry and make conflicting repeat attempts visible.
Where the workflow spans several services, a deterministic orchestration layer may be preferable for approvals, compensating actions or durable waiting states. EventBridge, SQS and Step Functions can participate in such systems, but they do not turn a probabilistic tool choice into exactly-once business execution by themselves. Separate the agent’s recommendation from the service transaction and design a reconciliation path for ambiguous outcomes.
Rate limits, deadlines and cancellation matter as well. If an agent requests several searches while a user has already abandoned the session, stop unnecessary work; do not cancel a committed business transaction merely because the conversational connection ended. A tool that times out should return a clearly classified state. The agent should not infer success from the intention to call a tool, and the UI must not tell the user a change was made until the backend confirms it.
Test the least-privilege path with a fictional service ticket
Build an acceptance matrix for an authorized technician, another department’s technician, a read-only auditor and an unauthenticated caller. Test tool discovery, access to the permitted record, access to a forbidden record, malformed arguments, stale ticket versions, missing approval, duplicate idempotency keys and partial backend failures. Verify not only that denied actions fail but also that they do not reveal the existence or contents of unrelated customers’ records through error messages.
Then introduce an indirect prompt injection in a retrieved ticket and check whether it can expand tool access, alter the approval process or influence the identity used by the backend. Record the invoked tool, trusted caller identity, decision result, argument validation outcome and transaction identifier without exposing raw secrets. If the agent cannot complete an action safely, it should return the proposed next step and a traceable limitation rather than attempting an undocumented workaround.
Successful AgentCore integration is not measured by the number of tools a model can discover. It is measured by controlled capability: the right identity may perform the right action on the right object, failures can be classified and recovered, and a human can understand what occurred. AgentCore Gateway and MCP provide valuable connectivity, but durable security and transaction correctness remain explicit engineering responsibilities.
Combine authorization and failure recovery in one controlled exercise. A technician may read only their team’s ticket, a security auditor may inspect an approved metadata view, and a caller whose token has the wrong audience must be denied before the protected tool executes. Then simulate a ticket closure whose backend succeeds but whose response is lost; the agent must reconcile the operation receipt rather than close the ticket twice. AgentCore Gateway’s inbound and outbound identity controls and the backend’s record-level authorization are related but not equivalent. Independent AWS AIP-C01 AgentCore practice scenarios should demand the exact enforcement point, narrow schema, permission evidence and idempotent outcome, rather than assuming MCP tool discovery grants permission to run every advertised operation.