# Anthropic updates its usage policy for agentic and cybersecurity risks > Anthropic published usage-policy updates that added detail for malicious computer, network, and infrastructure compromise activities. The company framed the changes around more capable agentic tools and cybersecurity risks, with an effective date stated in the announcement for the revised policy and explicit prohibited conduct categories. Canonical: https://hypler.com/ai-news/anthropic-usage-policy-update-2025 Hypler publication: 2026-10-06 Hypler updated: 2026-10-10 Original source date: 2025-08-15 Byline: Hypler editorial team Source publisher: Anthropic Editorial standard: https://hypler.com/ai-news#editorial-standard Article kind: source-briefing Category: Policy Tags: agent-safety, cybersecurity, policy ## Engineering relevance Tool-enabled workflows need explicit permissible-action boundaries and auditability. Model provider terms as external constraints alongside product authorization, user intent, and controlled execution design. ## Policy update in context Anthropic published usage-policy updates that added detail for malicious computer, network, and infrastructure compromise activities. The company framed the changes around more capable agentic tools and cybersecurity risks, with an effective date stated in the announcement for the revised policy and explicit prohibited conduct categories. This is a provider policy announcement from August 15, 2025, not a statement about every later Anthropic product or a substitute for a customer's own authorization controls. Provider policy is one external constraint in a system that also needs product-level intent, permission, and audit design. ## Policy cannot be the only guard Tool-enabled workflows need explicit permissible-action boundaries and auditability. Model provider terms are external constraints alongside product authorization, user intent, and controlled execution design. A safe product cannot assume that a model refusal is a complete control, because prompts can be ambiguous, tool arguments can be malformed, and downstream services may have broader credentials than the user intended. The application must decide which tool exists in a workflow, which operations it permits, which arguments are validated, who can request it, and what record is retained when it refuses, succeeds, or partially fails. ## Make authority narrower than capability A useful architecture gives the model a catalog of small, typed operations instead of a general shell or unrestricted network connector. Each operation has a purpose, input schema, authorization check, rate limit, and log classification. The model can propose a call, but an execution service evaluates the request against user role, task state, and destination policy. That separation resembles Hypler's public distinction between capability management and execution authority. It also makes provider changes survivable: a policy update may require a product change, but the local authority layer remains the place where actual privileges are enforced. ## Failure cases at the tool boundary The dangerous path is not only an obviously malicious request. It includes a benign support prompt that smuggles an unapproved destination, a tool description that exposes more options than the UI, or a retry that changes the target after an initial timeout. Another failure is audit theater: logging the model's final sentence while omitting the actual tool arguments, authorization result, and external response class. A reliable system fails closed when an intent cannot be matched to a permitted operation, emits a reason the user can act on, and avoids retaining sensitive payloads solely to make debugging convenient. ## Hypothetical permissioned automation In a hypothetical Hypler operations assistant, a user asks to prepare a diagnostic report. The assistant can query a redacted status endpoint and draft a summary, but it cannot change infrastructure, invoke a remote command, or contact a third party. Its tool contract rejects hostnames outside an approved set and strips secrets from returned values. A reviewer sees the requested report scope before export. If the status endpoint is unavailable, the result says that evidence could not be fetched rather than inferring a healthy state. The workflow is useful while its allowed actions stay much smaller than the model's ability to describe actions. ## Acceptance tests for bounded tools Tests should prove that omitted user authorization blocks an otherwise valid tool call, an unknown argument is rejected rather than ignored, and retry logic cannot broaden a destination or permission. Include prompt-injection fixtures embedded in tool output, sensitive-looking values in a simulated response, policy-denied requests, and partial upstream failures. Verify that logs contain a stable request ID, operation name, policy result, and redacted failure category. This record supports investigation without claiming that the provider policy or the model itself guarantees safety. It also leaves historical AI wording intact for the vendor policy while Hypler's first-party direction uses SI terminology. ## Implementation detail Provider policy should be represented as enforceable product boundaries, not copied into a prompt and hoped for. A tool-enabled workflow can classify requested work before model invocation, then select from a small set of tool capabilities whose scopes are fixed in code. A read-only repository search, for example, should not share credentials, network reach, or command execution with a remediation workflow. The authorization record needs both the requesting principal and the target resource; an instruction such as fix the server is not permission to touch an unspecified system. Keep a second check after model output because a model can propose an action that the original request did not authorize. Cybersecurity-oriented evaluation should include indirect attempts to expand scope through content, encoded instructions, tool descriptions, or multi-step plans. Test that the classifier fails closed when confidence is insufficient and that an escalation shows the reason without leaking sensitive context. Rate limits, short-lived credentials, sandboxed execution, and review queues address different failure modes and should not be collapsed into one control. When policy changes, map each affected capability to a product owner, test suite, and disable path. This keeps external terms visible while leaving operational security decisions under the product team's own authorization model. ## Original source - [Anthropic](https://www.anthropic.com/news/usage-policy-update) ## Related links - [Anthropic policy announcement](https://www.anthropic.com/news/usage-policy-update) - [MCP integration](/mcp-integration) - [LNSAT](/lnsat) - [SI agent governance and authorization](https://hypler.com/ai-agent-governance) ## Image provenance ### Primary image ![Generated illustration of precision testing equipment, a metaphor for AI evaluation.](https://hypler.com/assets/news/evaluation-lab.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography. - [Image source](https://hypler.com/ai-news/media.md) ### Supporting image ![Generated illustration of evidence records passing through a permission gate; not a compliance certification.](https://hypler.com/assets/news/policy-evidence.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography. - [Image source](https://hypler.com/ai-news/media.md) ## Reading boundary Historical source briefing with Hypler engineering analysis. Source details reflect the original publication date; implementation examples are hypothetical. Public reading grants no private access or execution authority.