待翻译：Authoring Dogwood policies from natural language in Amazon Bedrock AgentCore

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

AI agents can automate complex workflows but might take actions that don’t align with your organization’s policies or regulatory constraints if used without proper controls. To address this, we built Policy in Amazon Bedrock AgentCore so teams can implement controls that are applied across agents running in Amazon Bedrock AgentCore. This was recently expanded with new capabilities for enforcing restrictions that constrain agent actions across time, which support policies such as rate limiting, prerequisites and sequential ordering of tool calls, and cumulative effects. These policies are expressed in Dogwood, an open source governance language, and applied to agent actions in real time by the Dogwood monitor built into the AgentCore Gateway, a capability of Amazon Bedrock AgentCore. As part of this new launch, we expand the capabilities of Policy Authoring, an AI-driven tool to convert natural language policy specification documents into syntactically and semantically correct Dogwood formal specifications. With this new feature, you can generate policies that enforce temporal and trajectory constraints, invoke Amazon Bedrock Guardrails services to detect inappropriate content in the semantic meaning of free-form text, as well as policies that place restrictions on the input parameters of tools which were available in the previous version of Policy in AgentCore. Whatever your technical background, you can import policy documents written in natural language directly into the policy in Amazon Bedrock AgentCore to safeguard your deployed agentic systems. In this post, we demonstrate this new capability using examples and provide guidance on how you can use best practices when constructing natural language policies. Automated translation of natural language policies to Dogwood Dogwood policies can be written entirely by hand, and for a small set of controls that is a perfectly reasonable place to start. Policy Authoring works best when you already have rules written in prose and the work in front of you is transcription rather than design. You can provide a document containing a clean set of rules: a list of policies, the rules section of an operating procedure, or a written paragraph of permitted or restricted actions. Authoring is a translator rather than a summarizer, so a document that interleaves its rules with rationale, background, and commentary is better pared down to the rules themselves first. Example setting To keep the examples concrete, let us consider a customer-servicing agent at a retail bank. It verifies callers, files disputes, issues refunds against disputed charges, moves funds between a customer’s own accounts, and can ask a supervisor to approve a charge. Its tools are reached through the AgentCore Gateway, and each takes a small set of arguments and returns a result: Tool Purpose Input Output verify_identity Step-up verification of the caller { account: String } { verified: Bool } initiate_transfer Moves funds between the customer’s accounts { account: String, dest_account: String, amount: Long } { confirmation: String } issue_refund Reverses a disputed charge { account: String, charge_id: String, amount: Long } { refunded: Bool } file_dispute Opens a dispute case { account: String, description: String } { case_id: String } request_approval Asks a supervisor to approve a charge { charge_id: String } { approved: Bool } Alongside the policy document, authoring takes a schema carrying exactly this information: the tool names, the arguments they accept, and the values they return. That schema is generated from the agent’s Model Context Protocol (MCP) tool manifest, so the policies that come out refer to the same names the agent actually calls. For example, context.input.amount in a generated policy is the amount argument in the preceding table. Authoring is also given the set of available Amazon Bedrock Guardrails checks, and identity claims that a policy is allowed to reference. The bank’s compliance team maintains its controls as a written document in the form it already uses for its human staff. The rules that follow are taken from that document, each followed by the Dogwood policy that Policy Authoring produced for it. Two conventions make the output more straightforward to read. Dogwood is default-deny and a forbid overrides a permit, so a rule that grants a capability becomes a permit carrying the conditions, while a rule that limits or caps something becomes a forbid. And a condition can examine either the call being decided or what has already happened in the same session. The following examples do both. Policy translation examples The following examples show how the autoformalizer translates natural language policies into Dogwood formulas. A constraint on a tool’s arguments Refunds might be issued only during business hours, defined as 9:00 AM–5:00 PM UTC, and only for amounts of $2,500 or less. permit ( principal, action == AgentCore::Action::"issue_refund", resource ) when { context.system.now.toTime() >= duration("9h") && context.system.now.toTime() 50000 ) }; Here, the history isn’t searched but added up. The policy takes the amount argument of every transfer in the past 12 hours, sums them, and denies the current call if the running total passes $50,000. Each individual transfer in that window might be small and unremarkable, but the condition instead constrains their aggregate. Note also what the document leaves open: it says “transferred” without saying whether a blocked or failed attempt counts. The translation sums ::request events, meaning every transfer the agent attempted, which is the safer reading for a cap. However, saying so in the document removes the guess, and that is the subject of the first best practice that follows. A rate limit The agent might attempt no more than three refunds against the same account within one hour. forbid ( principal, action == AgentCore::Action::"issue_refund", resource ) when temporal { exists (n: Long). ( (count for (t: Timepoint). where ( formerly within 1h ( AgentCore::Action::"issue_refund"::request{ input.account: context.input.account } && tp(t) ) )) == n && n > 3 ) }; This has the same shape as the previous policy, counting events rather than summing a field. The count is restricted to refunds against the account named in the call under consideration, and it includes that call, so the fourth attempt within the hour is the one that is denied. This rule says “attempt” explicitly, so unlike the previous one it leaves nothing to infer: a refund that was denied or that failed still counts against the limit. A check on free-form text Reject any dispute filing whose description contains a Social Security number. forbid ( principal, action == AgentCore::Action::"file_dispute", resource ) when { BedrockGuardrails::SensitiveInformation(["US_SOCIAL_SECURITY_NUMBER"], [context.input.description]) .maxConfidenceScore().greaterThanOrEqual(decimal("0.2")) }; Some rules are about the meaning of free-form text rather than a structured value, and no comparison on a field will decide them. For these, the generated policy calls an Amazon Bedrock Guardrails check inline, on the field the rule names, and compares the reported confidence against a threshold. This rule states no threshold, so the translation uses the default for that check. When a document does state one (for example, “with high confidence”, or a specific number), that value is carried through instead. A rule that draws on more than one kind of condition A refund of more than $500 requires a supervisor’s approval for that charge, recorded within the last 30 minutes. forbid ( principal, action == AgentCore::Action::"issue_refund", resource ) when { context.input.amount > 500 } unless temporal { formerly within 30m AgentCore::Action::"request_approval"::response{ input.charge_id: context.input.charge_id, output.approved: true } }; The sentence has two parts that are checked in quite different ways: a threshold on an argument of the current call, and a condition on what has already happened. Both clauses live in the same policy. The rule narrows an existing permission: it denies refunds over $500, and the unless clause is the exception that lifts the denial when a matching approval is on record. As in the earlier prerequisite example, the correlation on charge_id is what stops an approval for one charge from authorizing a refund on another. Best practices Clear and unambiguous policies result in more predictable behaviors and fewer errors, whether the implementer is a human user or an autonomous agent. As well, this improves the performance of the natural language to Dogwood authoring solution introduced earlier. Next, we review a handful of tips and best practices for constructing natural language policies. Say whether you mean the attempt or the outcome. “After a transfer” is ambiguous. “After a transfer succeeds” is not. An attempt is any call the agent issued, including ones that were denied or failed. Only a completed call carries the values the tool returned. Rate limits and cumulative caps are usually about attempts, prerequisites and ordering rules about outcomes. State the window. “Recently” has no translation. “Within the past 30 minutes” does. Windows look backward from the call being decided, so if a rule is meant to reset on a calendar boundary rather than slide with the clock, state that explicitly, because it requires a different control. Name what the rule is keyed to. “No more than three transfers per hour” does not say whose: three by this caller, or three against this account? Both are expressible, they are different policies, and the sentence chooses neither. Wherever a rule counts, sums, or correlates, name the field that ties the events together. Give the threshold and its boundary. “More than three” and “at least three” differ by one action, usually the one the rule exists to stop. The same applies to the confidence levels on content checks. Review the generated Dogwood policies for correctness. Each Dogwood policy is returned alongside the sentence it came from, so that you can read the two side by side. While validation can establish that a policy is well-formed and anchored in the right schema, it doesn’t confirm that the policy says what its author meant. That judgment stays with the person who owns the document. Knowing what can’t be enforced While the authoring service can filter out and highlight policies that are incompatible with enforcement by Policy in AgentCore, you should also be aware of the common issues. It isn’t a rule about an action. “Agents should always act in the customer’s best financial interest and exercise sound professional judgment.” There’s no condition here on any action, field, or principal. This is a real requirement, and it belongs in the agent’s instructions, its evaluations, and its training, rather than in an authorization engine. It asks for an action, not a verdict. “When a dispute description contains a Social Security number, redact it before the note is stored.” A policy engine permits or denies a call. It doesn’t modify one. The neighboring rule that denies a filing containing a Social Security number is expressible and appears among the preceding examples. Redaction is a different control, applied at a different point in the pipeline. It is outside what the language expresses. “Deny wire transfers on weekends and U.S. federal bank holidays.” The date and time support in Dogwood covers points in time, offsets, and differences. There is no day-of-week accessor and no holiday calendar. The Dogwood language guide sets out in detail which constructs are available, and it is worth reading through that guidance when a rule is set aside by the policy authoring service, both to confirm the gap and to see whether a nearby formulation is supported. It’s outside the scope of enforcement. “A customer might initiate at most t [truncated for AI cost control]