strands-agents

17 things your agent harness should have! Do this first: go down the list and tick what your harness already does. Each unticked item is a failure your agent will hit. The list comes from reading the source of [OpenHands SDK][oh], [OpenCode][oc], [Hermes Agent][ha], [DeepSeek harness][ds] and [Strands harness][st]. Items 1–6 are the basics everyone builds. Items 7–17 are what separates these harnesses from a model in a loop. The rule behind all of them: the prompt is for judgement; anything a script can check is enforced in code. The list 1. A tool loop. Model call, tool calls, results back, repeat until the model answers. Everything else hangs off it. 2. Summarization. Old turns get summarized so long runs keep going. OpenHands keeps the first messages untouched and makes the summary track open tasks ([condenser][oh-condense]); Strands never drops pinned messages ([summarizing manager][st-summ]). 3. Subagents. Hand a focused task to a fresh agent with its own tools, and get back one answer ([Strands subagent.py][st-sub]). 4. Skills. Instructions loaded only when the task needs them. OpenHands loads them on keywords and on file paths the agent touches ([trigger.py][oh-skills]). 5. Model retries. Back off and retry on provider errors. Strands defaults to 6 attempts ([_retry.py][st-retry]). 6. Hooks. Run your own check before or after any tool call, on each prompt, and on stop. OpenHands follows Claude Code's convention: a hook that exits with code 2 blocks the call ([hooks/manager.py][oh-hooks]). 7. Errors that name the next step. A refusal says why and what to do instead. OpenCode answers a missing file with "Did you mean one of these?" ([read.ts][oc-read]); DeepSeek's sandbox says "retry this exact command once with sandbox_permissions + justification" ([escalation.ts][ds-esc]). 8. Read before edit. Refuse an edit to a file the agent never read, or one that changed since: edit requires reading "X" first ([DeepSeek][ds-read]). Hermes warns "was modified since you last read it" ([read tracking][ha-read]). 9. Repeated-call detection. Same tool, same arguments, again. DeepSeek reminds at 3, 5 and 8 repeats ([repeat-tool-reminder][ds-repeat]); Hermes warns, then blocks, then halts ([tool_guardrails.py][ha-guard]); OpenHands nudges once, then stops the run ([stuck_detector.py][oh-stuck]). 10. A step budget that takes tools away. When it's spent, OpenCode sets toolChoice: "none", appends a wrap-up message, and refuses any call that still arrives ([max-steps.ts][oc-steps], [llm.ts][oc-llm]). The run ends with an answer, not a crash. 11. "Done" is checked, not trusted. Hermes sends the model back to run its tests after a code edit ([verification_stop.py][ha-verify]). OpenCode's judge is told "The assistant claiming the goal is met is not evidence" ([judge.txt][oc-judge]). 12. Remove tools instead of forbidding them. OpenHands' planning agent can only edit PLAN.md ([planning.py][oh-plan]); OpenCode's explore agent starts from deny-all ([agent.ts][oc-agent]); Hermes subagents never get delegate or memory tools ([delegate_tool_toolsets.py][ha-sub]). 13. Parse shell commands before running them. OpenCode checks each command and target folder as a permission ([shell.ts][oc-shell]). Hermes keeps a blocklist no mode can override ([approval_floors.py][ha-floor]). 14. Reminders checked against state. Before every request OpenCode checks the last plan-mode reminder still matches the current mode ([plan.ts][oc-plan]). Strands re-adds the todo list each turn without saving it to history ([todos.py][st-todo]). 15. Silent argument repair. "42" becomes 42 before the tool runs ([Hermes arg_coercion.py][ha-coerce], [OpenCode tool-input-repair.ts][oc-repair]). No round trip, no error. 16. Summaries that don't give orders. Hermes labels them "REFERENCE ONLY … NOT as active instructions", after a stronger wording made the agent stop using tools ([context_compressor.py][ha-compact]). DeepSeek keeps user corrections word for word ([summarizer.ts][ds-sum]). 17. An LLM supervisor with hard limits. Hermes' guardian model rates risky commands and stops after repeated denials ([approval_smart.py][ha-smart]). Strands' judge must "treat partial satisfaction as failure" ([judge.py][st-judge]). A judge without a numeric cap is just another loop. Start here Have 1–6 already? Build 8, 9 and 10 next. Each is about a day of work and removes a whole class of failures. Next: open your file-edit tool and check whether it refuses an edit to a file the agent never read. [oh]: OpenHands/software-agent-sdk [oc]: anomalyco/opencode [ha]: NousResearch/hermes-agent [ds]: deepseek-ai/deepseek-harness [st]: strands-agents/harness-sdk [oh-condense]: github.com/OpenHands/software-agent-sdk/blob/295b… [st-summ]: github.com/strands-agents/harness-sdk/blob/3bd9ed… [st-sub]: github.com/strands-agents/harness-sdk/blob/3bd9ed… [oh-skills]: github.com/OpenHands/software-agent-sdk/blob/295b… [st-retry]: github.com/strands-agents/harness-sdk/blob/3bd9ed… [oh-hooks]: github.com/OpenHands/software-agent-sdk/blob/295b… [oc-read]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [ds-esc]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ds-read]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ha-read]: github.com/NousResearch/hermes-agent/blob/53a6ced… [ds-repeat]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ha-guard]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oh-stuck]: github.com/OpenHands/software-agent-sdk/blob/295b… [oc-steps]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [oc-llm]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [ha-verify]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oc-judge]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [oh-plan]: github.com/OpenHands/software-agent-sdk/blob/295b… [oc-agent]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [ha-sub]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oc-shell]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [ha-floor]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oc-plan]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [st-todo]: github.com/strands-agents/harness-sdk/blob/3bd9ed… [ha-coerce]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oc-repair]: github.com/anomalyco/opencode/blob/2658ec02c848ce… [ha-compact]: github.com/NousResearch/hermes-agent/blob/53a6ced… [ds-sum]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ha-smart]: github.com/NousResearch/hermes-agent/blob/53a6ced… [st-judge]: github.com/strands-agents/harness-sdk/blob/3bd9ed…

How to Steer the model via tool call to improve Harness Quality Your agent does something it shouldn't, so you add a line to the system prompt. It still slips, just less often. Repeat that for a year and you have a long prompt the model half-follows. The open-source harnesses ([OpenHands SDK][oh], [OpenCode][oc], [Hermes Agent][ha], [DeepSeek harness][ds], [Strands][st]) work differently. If a script can decide whether the model is doing the wrong thing, they check it in code when the model calls the tool. The call is rejected, and the error says what to do instead. The model reads that on its next turn, so it doesn't have to remember a rule from thousands of tokens ago. Here is how that plays out on problems every agent hits. It edits a file it never read The usual fix is a prompt line: always read a file before editing it. But the harness already knows whether the file was read. DeepSeek keeps a record of every read and refuses the edit with edit requires reading "X" first ([fs-observation-policy][ds-read]). The model reads the file and tries again. It retries the same failing call You could write don't repeat a command that failed. But "same tool, same arguments" is a string comparison. Hermes counts identical calls, and on the fifth it blocks with "Stop retrying it unchanged; change strategy or explain the blocker" ([tool_guardrails.py][ha-guard]). DeepSeek sends a reminder at 3, 5 and 8 repeats instead of blocking ([repeat-tool-reminder][ds-repeat]). It runs a command the wrong way When the model wraps a command in nohup, Hermes refuses it and hands back the exact call to make: "Re-send WITHOUT the wrapper as terminal(command=…, background=true)" ([terminal guards][ha-term]). OpenHands does the same when the model chains commands ("Cannot execute multiple commands at once", [terminal_session.py][oh-multi]) or passes a relative path ("Maybe you meant /abs/path?", [editor.py][oh-path]). None of this needs a prompt paragraph; the mistake is visible in the call itself. PDFs work the same way. If the model tries to cat a PDF, the harness can refuse and point to the parse tool. Better, the read tool can parse the PDF itself, save the text, and reply "Parsed. Read paper.md." The model never sees a failure. It says "done" without testing Always run the tests before finishing is another rule the run's own history can check. Hermes turns a final answer given right after a code edit into one more turn: "Run the relevant verification command now", at most three times ([verification_stop.py][ha-verify]). OpenHands lets a Stop hook refuse the finish and feeds its reason back as "[Stop hook feedback] …" ([local_conversation.py][oh-stop]). Where the prompt still wins Which source to search, or how to structure a report, is judgement, and a hard block there stops good runs too. These harnesses leave judgement to instructions that load when relevant: OpenHands loads skills by keyword and by the files the agent touches ([trigger.py][oh-skills]). Even plan mode is prompt-only in Hermes ([plan_prompt.py][ha-plan]) and DeepSeek ([plan-mode README][ds-plan]). The line is simple: if a script can check it, enforce it at the tool call. If it needs judgement, put it in a skill. Hooks let you add checks without touching tools Every harness here also runs hooks, your own script before or after a tool call. DeepSeek turns a hook's deny into an error the model reads, and when several hooks answer, the strictest wins ([merge.ts][ds-merge]). OpenHands follows Claude Code's convention that a hook exiting with code 2 blocks the call ([hooks/manager.py][oh-hooks]). OpenCode goes one step further: when a user rejects a call and types why, that text becomes the error the model sees ([permission.ts][oc-corrected]). Isn't this custom code? No. It's the harness doing its job, and part of why OpenCode, Hermes and the OpenHands SDK each run past 20k lines outside their prompts. The full list of what a harness should have is in [the companion post][blog1]. Next: find one line in your system prompt that starts with "never" or "always". If a script could check it, move it to the tool call. [blog1]: dev.to [oh]: OpenHands/software-agent-sdk [oc]: anomalyco/opencode [ha]: NousResearch/hermes-agent [ds]: deepseek-ai/deepseek-harness [st]: strands-agents/harness-sdk [ds-read]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ha-guard]: github.com/NousResearch/hermes-agent/blob/53a6ced… [ds-repeat]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ha-term]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oh-multi]: github.com/OpenHands/software-agent-sdk/blob/295b… [oh-path]: github.com/OpenHands/software-agent-sdk/blob/295b… [ha-verify]: github.com/NousResearch/hermes-agent/blob/53a6ced… [oh-stop]: github.com/OpenHands/software-agent-sdk/blob/295b… [oh-skills]: github.com/OpenHands/software-agent-sdk/blob/295b… [ha-plan]: github.com/NousResearch/hermes-agent/blob/53a6ced… [ds-plan]: github.com/deepseek-ai/deepseek-harness/blob/b150… [ds-merge]: github.com/deepseek-ai/deepseek-harness/blob/b150… [oh-hooks]: github.com/OpenHands/software-agent-sdk/blob/295b… [oc-corrected]: github.com/anomalyco/opencode/blob/2658ec02c848ce…

The harness is your attack surface You install a coding agent and point it at a repo. Which files can it read, and what stops it? For some setups the honest answer is "everything your user can." The harness gives you control points, but the boundary and the policy are yours. A note on method. I read the current documentation of two open-source agent projects, OpenHands and the Strands Agents Python SDK, plus a harness-engineering survey. Every factual statement below carries a marker like `` that maps to one of those three sources. Where I give an opinion or a reading of a README, I say so. I do not call any project "safer" than another, because I found no comparison made on equal terms. 1. The default question: where does the agent run? Start with the most uncomfortable line in the OpenHands README. It documents that running the agent without a sandbox gives it full access to the host filesystem. What matters is where the code runs in that mode. Without a sandbox, the OpenHands agent-server runs directly on the host machine rather than in a container. Fine for a throwaway laptop. A very different choice on a developer machine that holds SSH keys, cloud credentials and ten other repositories. I'd settle the run mode before the first task, not after the first surprise. A cheap habit: in your own wrapper, print the run mode at the start of every task and stop if it is not the one you expect. 2. Docker helps, but only as far as you mount OpenHands can run each new conversation in its own Docker container, with its own Agent Server and tools. That narrows what one conversation can break. !Two columns: a narrow mount exposes one project for one task; a broad PROJECTS_PATH exposes every repository under it. The catch is the mount. In the Docker sandbox option, the agent can access any project under PROJECTS_PATH, a host directory the user chooses. The container is only as narrow as the directory you hand it. Here is the difference, as an illustration of the idea rather than a copy of any official setup: # Narrow: one project only. The narrow path is the whole point: one task, one repo. export PROJECTS_PATH="$HOME/work/payments-service" # Broad: every project you have ever cloned (commented out so this block is safe to paste) # export PROJECTS_PATH="$HOME/work" With the second value, a task about one service can reach every other repository under that directory, because the documented behaviour is access to any project under the path. 3. The control plane sits outside the sandbox Isolating where the agent executes does not harden the service around it. Per-conversation Docker isolation in OpenHands does not sandbox the whole Canvas or automation service. Treat that service as its own system to harden. For internet-facing installs, OpenHands points readers to its self-hosting guide for security hardening, and the project is MIT licensed. I did not open that guide, so read it yourself before exposing an install. 4. What Strands gives you: control points, not a policy The Strands Agents SDK takes a different shape. Its README lists a set of control points. I group them by the job they do: !A three-step chain: set limits such as turn limits and budgets, add hooks to log each step, then use steering to recover. - Observe. Hooks let you intercept any step to log it, validate it or redirect it. - Limit. Guardrails catch mistakes before they run. Lifecycle controls include turn limits, token budgets, cancellation and stop reasons. - Recover. Steering handlers let agents correct themselves instead of failing silently. My opinion on order: set the limits first, then add hooks so you can see what the limits catch. A single create_harness() call in Python, or createHarness() in TypeScript, returns an optimized agent, in the README's words. The SDK is Apache-2.0 licensed. These are mechanisms. My reading of the README excerpt is that it states no default policy, so what to block, what budget to set and what to log would fall to whoever deploys it; check the repository before relying on that. The README excerpt I used shows no hook example, so for working code, go to the repository. 5. What the survey says is still open The harness-engineering survey gives an outside view. It says it covers 110+ papers and 23+ deployed systems, and identifies nine open challenges. Security and sandboxing is challenge number one. The survey attributes 15–35% frontier-model container escape rates to a benchmark it calls SandboxEscapeBench, and I saw that figure only second-hand, so treat it as the survey's claim. The survey's advice is blunt: treat sandboxing as a hard requirement and apply defense-in-depth. It also lists a harness-specific threat model, covering tool hijacking, context poisoning and agent impersonation, as future work. For anyone planning multi-agent setups, one more line stands out. The survey says Byzantine fault tolerance remains unsolved for adversarial multi-agent settings. The term comes from the problem of getting generals who communicate only by messenger to agree on a plan when some may be traitors, per Lamport, Shostak and Pease. 6. What I would ask for before a pilot This section is my opinion, not a sourced finding. If I were setting a baseline for coding agents in a company, I would ask for these before the first pilot: !A six-item checklist: sandbox on by default, narrow mounts, hardened control plane, explicit budgets, logging hooks, human approval for high-stakes steps. 1. Sandbox on by default, with the run mode checked in tooling, so nobody discovers the host-level mode by accident. 2. Narrow mounts: one project per task, so one mistake stays small. 3. The control plane treated as its own system to harden, separate from the execution sandbox, since the sandbox does not cover it. 4. Budgets and turn limits set explicitly, so a runaway task stops. 5. Hooks that log every step, so you can see what happened. 6. Human approval for high-stakes steps, so a person owns the risky calls. The last items line up with the survey's governance layer, which covers security constraints, human handoff points, HITL policy, audit trails and compliance enforcement. Separately, in its section on multi-agent fault tolerance, the survey recommends gating high-stakes coordination on human approval. Each item is cheap to check before a pilot and expensive to retrofit. Ask each team to show, not describe, the run mode, the mount, the budget and the log. If any of the four is "we will look into it", the pilot is not ready. None of this needs a particular product; it needs someone to own the answers, hence the question below. Draw the boundary before the agent runs. Which boundary do you enforce today for coding agents, and who owns it on your team?

Source: strands-agents/box. Preview, macOS Apple silicon only. A sandbox narrows what an agent can reach; it isn't a safety guarantee. What would you deny by default?

Your AI Agent Runs Code. What Stops It? Strands Box is an open-source sandbox for AI agents from the Strands Agents project, written in Rust. Three ideas: default deny, policies with memory (per the README, reading a file can get a later outbound request denied), and a credential gateway so the agent never holds your keys. It restricts what an agent can do; it doesn't make it safe on its own. Preview, macOS on Apple silicon only. Voiceover is AI-generated. Repo: strands-agents/box #shorts #aiagents #security #rust #github #opensource

AWS Agentic AI Services: Build an Intelligent Architecture Workflow on AWS What if you could describe an application in plain English and have an AI-powered workflow help you design its AWS architecture, review security requirements, identify cost drivers, and prepare infrastructure code? !Image description That is the idea behind agentic AI. A traditional AI chatbot can recommend AWS services and explain how they work. An agentic workflow can go further by coordinating tasks, using approved tools, checking intermediate results, and revising its recommendations when problems are found. In this article, we'll explore how to build an AWS Architecture Copilot using Amazon Bedrock, Bedrock AgentCore, Strands Agents, AWS Lambda, and other AWS services. We'll also create a small Python validation example and discuss how to keep the workflow secure. 1. What Makes Agentic AI Different? Consider this request: > Design a secure and cost-effective AWS architecture for an online store with a web frontend, product API, relational database, and product-image storage. A basic chatbot might suggest Amazon S3, Amazon RDS, and compute services. An agentic workflow could coordinate several additional steps: 1. Analyze the application requirements. 2. Retrieve relevant architecture standards. 3. Propose an AWS architecture. 4. Review the design against security requirements. 5. Identify missing information for cost estimation. 6. Generate an infrastructure-as-code proposal. 7. Request approval before deployment. The important difference is not simply using a more advanced model. It is coordinating reasoning, tool use, validation, and controlled actions. These capabilities must be implemented in the application; they are not automatically provided as one complete workflow by a single AWS service. 2. AWS Services for an Agentic Workflow Here are the main building blocks. Amazon Bedrock Amazon Bedrock provides access to foundation models for generative AI applications. A model can interpret requirements, generate structured recommendations, summarize technical documentation, and help an agent choose among its available tools. Documentation: docs.aws.amazon.com Amazon Bedrock AgentCore AgentCore provides modular capabilities for deploying, connecting, securing, and monitoring agents. Depending on your architecture, you may use: - Runtime to run agents. - Gateway to connect agents to approved tools and APIs. - Memory to retain relevant context. - Identity and Policy capabilities to support controlled access and actions. - Observability and Evaluations to inspect and assess agent behavior. You can use the capabilities that fit your application instead of adopting every component at once. Documentation: docs.aws.amazon.com Strands Agents Strands Agents is an open-source SDK for building AI agents. It helps developers define agent behavior and connect models to tools. It can be used to implement an architecture planner, a security reviewer, or a coordinator for a multi-step workflow. GitHub: github.com/strands-agents Other AWS Services | Service | Role in the workflow | |---|---| | Amazon S3 | Store architecture documents and generated artifacts | | Amazon Bedrock Knowledge Bases | Retrieve relevant approved technical information | | AWS Lambda | Run bounded validation and helper functions | | AWS Step Functions | Coordinate predictable steps, retries, and approvals | | AWS IAM | Apply least-privilege access | | Amazon CloudWatch | Collect logs, metrics, and alarms | | AWS CloudFormation or AWS CDK | Define infrastructure as code | A useful design principle is to use agents for flexible analysis and conventional software for deterministic rules and controlled execution. 3. Reference Architecture The following is a proposed architecture for an AI Architecture Copilot. Developer | v Web Application / API | v Workflow Coordinator | v AgentCore Runtime + Strands Agents | +------------------+------------------+ | | | v v v Architecture Security Cost Planner Reviewer Analyst | | | +------------------+------------------+ | v Schema and Rule Checks | +--------+--------+ | | v v Needs Changes Ready for Review | | v v Revise Plan Human Approval | v Controlled Deployment | v AWS Resources The application can use Amazon Bedrock for model access, AgentCore for agent operations, S3 and Knowledge Bases for reference information, Lambda for validation, and Step Functions for workflow coordination. The deployment stage can use CloudFormation or CDK through a controlled pipeline. This is a reference design, not a deployed solution. The integrations and permissions must be implemented and tested. 4. Design the Agent Roles You do not necessarily need four separate agents. These roles can be implemented as independent agents or as stages within one agentic application. Architecture Planner - Extracts requirements. - Recommends AWS services. - Identifies dependencies. - Produces a structured architecture specification. Security Reviewer - Reviews network and identity assumptions. - Checks whether data-protection requirements are addressed. - Identifies missing evidence. - Returns findings and remediation recommendations. Cost Analyst - Identifies compute, storage, database, and data-transfer cost drivers. - Requests missing workload assumptions. - Uses verified pricing data where available. - Clearly labels estimates and unknowns. Infrastructure Planner - Prepares CloudFormation or CDK artifacts. - Validates generated files. - Summarizes proposed infrastructure changes. - Waits for approval before deployment. The benefit is separation of responsibility. A security reviewer should independently examine the architecture instead of simply repeating the planner's recommendations. Multiple agents do not automatically mean better results, so test their outputs and measure their performance. 5. Mini Project: Validate Architecture Requirements with Python Before sending a request to an AI agent, validate the input. Missing or inconsistent requirements can lead to poor recommendations. Create a file named requirements.json: { "application": "online-store", "region": "us-east-1", "frontend": "web", "api": true, "relational_database": true, "product_image_storage": true, "requirements": { "private_database": true, "monitoring": true, "human_approval_before_deployment": true } } Now create validate_requirements.py: import json import sys REQUIRED_FIELDS = { "application", "region", "frontend", "api", "relational_database", "product_image_storage", "requirements", } def validate_requirements(filename): with open(filename, encoding="utf-8") as file: data = json.load(file) missing = REQUIRED_FIELDS - data.keys() if missing: raise ValueError( f"Missing fields: {', '.join(sorted(missing))}" ) requirements = data["requirements"] if not isinstance(requirements, dict): raise ValueError("'requirements' must be an object.") required_controls = ( "private_database", "monitoring", "human_approval_before_deployment", ) missing_controls = [ key for key in required_controls if key not in requirements ] if missing_controls: raise ValueError( "Missing controls: " + ", ".join(missing_controls) ) if requirements[ "human_approval_before_deployment" ] is not True: raise ValueError( "Human approval must be enabled before deployment." ) print("PASS: Required input fields are present.") print("PASS: Human approval is enabled.") print("Next: Generate and review the architecture proposal.") if __name__ == "__main__": filename = ( sys.argv[1] if len(sys.argv) > 1 else "requirements.json" ) try: validate_requirements(filename) except ( OSError, json.JSONDecodeError, ValueError, ) as error: print(f"FAIL: {error}") sys.exit(1) Run the script: python validate_requirements.py requirements.json Expected output: PASS: Required input fields are present. PASS: Human approval is enabled. Next: Generate and review the architecture proposal. This example validates input fields and the approval setting. It does not verify that the proposed architecture is secure, correctly configured, or deployable. For production, add JSON Schema validation, type checks, allowed-value checks, and tests for malformed input. 6. Give the Architecture Agent a Defined Task Once the input is validated, an agent can analyze the requirements and produce a structured proposal. For example: You are the Architecture Planner for an AWS Architecture Copilot. Analyze the supplied requirements and approved architecture references. Return a structured proposal containing: 1. Recommended AWS services 2. Purpose of each service 3. Network and data-flow relationships 4. Security assumptions 5. Availability and scaling considerations 6. Missing requirements 7. Validation checks Rules: - Do not invent requirements. - Mark assumptions and unknowns explicitly. - Use approved architecture references when available. - Do not claim checks passed without evidence. - Do not deploy or modify AWS infrastructure. - Return machine-readable JSON. Your application should validate the returned JSON before passing it to the security-review stage. The Security Reviewer can then return a status such as PASS, FAIL, or UNKNOWN, along with findings and supporting evidence. Never treat UNKNOWN as PASS. If important information is missing, stop and request clarification. 7. Cost Analysis and Infrastructure Generation After the architecture passes its required checks, the workflow can prepare cost and infrastructure artifacts. The Cost Analyst should identify inputs such as: - AWS Region. - Expected request volume. - Compute requirements. - Database size and availability. - Storage consumption. - Data transfer. - Logging and monitoring usage. Use verified AWS pricing data and document the assumptions behind the estimate. A model-generated number alone is not a verified price. The Infrastructure Planner can then prepare a CloudFormation template or CDK application. Validate the generated artifacts and review the proposed changes before allowing a deployment pipeline to execute them. 8. Security Controls for Production Giving an AI agent access to cloud tools introduces risks. Build the controls into the architecture from the beginning. - Least privilege: Give each component only the permissions it requires. - Approved tools: Expose narrowly scoped operations instead of unrestricted AWS access. - Human approval: Require explicit authorization for impactful changes. - Input and output validation: Reject malformed or incomplete data. - Secrets management: Never place credentials in prompts or generated source files. - Auditability: Record tool calls, validation results, approvals, and deployment outcomes. - Bounded execution: Apply timeouts, retry limits, and resource limits. - Evaluation: Test for incorrect recommendations, prompt injection, and unsafe tool use. - Rollback planning: Define a recovery path for unsuccessful deployments. Amazon Bedrock Guardrails can provide additional safeguards for supported model interactions. They do not replace IAM, application authorization, infrastructure validation, or security testing. 9. When Should You Use Agentic AI? Agentic workflows are useful when tasks involve multiple steps, changing context, tool usage, and decisions that may need revision. Potential use cases include: - AWS architecture recommendation. - Cloud migration planning. - Infrastructure troubleshooting. - Cost-optimization analysis. - Documentation and compliance preparation. - Developer workflow automation. However, a simple deterministic task may be better handled by a Lambda function or conventional workflow. Agents introduce additional latency, cost, complexity, and evaluation requirements. A strong production architecture combines flexible AI reasoning with deterministic controls. Conclusion Agentic AI can help developers move beyond one-off AI responses toward workflows that coordinate architecture design, security review, cost analysis, and infrastructure preparation. Using Amazon Bedrock, Bedrock AgentCore, Strands Agents, AWS Lambda, Step Functions, Amazon S3, IAM, and controlled deployment pipelines, teams can build an Architecture Copilot that turns natural-language requirements into a reviewable technical proposal. Start small, validate every important output, and measure the quality of the results before expanding the workflow. The goal isn't to give AI unrestricted access to AWS. It's to let AI handle more of the analysis while engineers stay in control of critical decisions. Official AWS Resources - Amazon Bedrock - Amazon Bedrock AgentCore - Strands Agents - Amazon Bedrock Knowledge Bases - AWS Lambda - AWS Step Functions - Amazon Bedrock Guardrails

Strands Box GitHub Explained: Deterministic Sandboxing for Autonomous AI Agents box by strands-agents: strands-agents/box Strands Box is an open-source Rust-based local sandbox for containing autonomous AI workloads. This overview explains why prompt-level controls are not enough, how deny-by-default enforcement separates OS containment from semantic policy, and how the egress gateway keeps credentials outside the agent workload. It covers macOS Apple Silicon Seatbelt enforcement, explicit binary and workspace paths in box.toml, Dogwood policy evaluation, temporal state tracking, and the HTTP/1.1 proxy constraint discussed for Node.js agents using cloud SDKs. The 0.1 developer preview is optimized for macOS on Apple Silicon; use the repository to verify current schemas, configuration syntax, and platform limits. TimeStamps: 0:00 Why prompt-level controls fail for autonomous agents 1:07 Strands Box and deny-by-default containment 2:10 box.toml, policy rules, and the two enforcement layers 2:35 macOS Seatbelt and OS-level constraints 3:41 Dogwood semantic policy inside the perimeter 4:27 Temporal state, action history, and self 5:17 Egress gateway and out-of-band credentials 6:43 The Node.js HTTP fallback constraint 6:53 How the layers interlock under default deny 7:31 Apple Silicon preview limits and repository guidance 🛡️ OS containment sets the hard boundary 🧠 Dogwood evaluates intent and execution history 🔐 Egress keeps credentials outside the agent workload For engineers evaluating AI agent security, the central takeaway is architectural: prompts can guide behavior, but they do not define a reliable execution boundary. Strands Box combines OS isolation, state-aware policy, and credential-aware egress to make allowed actions explicit. The repository’s platform notes matter, especially for the Apple Silicon developer preview. #StrandsBox #AIAgentSecurity #Sandboxing [de-DE] YNAS ynp_52667562436230c7 Cinematic Privater automatisierter Staging-Upload. Paketidentität: ynp_52667562436230c7; Ausgabe: cinematic. [es-US] YNAS ynp_52667562436230c7 cinemática Carga de entorno de prueba de automatización privada. Identidad del paquete: ynp_52667562436230c7; salida: cinematográfica. [fr-FR] YNAS ynp_52667562436230c7 cinématique Téléchargement de l'environnement de test d'automatisation privé. Identifiant du package : ynp_52667562436230c7 ; sortie : cinématique. [hi] YNAS ynp_52667562436230c7 सिनेमैटिक निजी स्वचालन स्टेजिंग अपलोड। पैकेज पहचान: ynp_52667562436230c7; आउटपुट: सिनेमाई। [id] YNAS ynp_52667562436230c7 sinematik Unggahan staging otomatisasi pribadi. Identitas paket: ynp_52667562436230c7; output: sinematik. [it] YNAS ynp_52667562436230c7 cinematografico Caricamento di automazione privata. Identità del pacchetto: ynp_52667562436230c7; output: cinematico. [pt-BR] YNAS ynp_52667562436230c7 cinematográfico Upload de teste de automação privada. Identificação do pacote: ynp_52667562436230c7; saída: cinemática.

Default-deny egress is underrated as a discovery tool, not a security one. Every rule I had to add to get my agent working was a confession: it was quietly calling something I never specified. The allowlist ended up being the real spec. strands-agents/box

strands-agents/box Apache-2.0, ~440 stars, v0.1.0 on Oct 7 and native file policy checks merged Oct 16. API keys get injected at the gateway so the agent never holds them, and every denial names the rule. Preview runs on Apple silicon Macs for now.

给 agent 一个默认拒绝的沙箱 Strands Box 用系统隔离加 Dogwood 策略做默认拒绝，凭证注入让密钥不进 agent 进程，现在支持 Apple 芯片的 macOS。 strands-agents/box t.co