As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Criação de políticas temporais

Você cria uma política temporal na linguagem de política do Dogwood e a adiciona a um mecanismo de políticas, da mesma forma que cria qualquer outra política para a Política em AgentCore. Uma política temporal é uma forbid regra permit ou cujas condições de reconhecimento de sessão são colocadas em um temporal bloco; o principal, a ação e o recurso aos quais a regra se aplica são escritos usando o (principal, action, resource) escopo padrão, da mesma forma que qualquer outra política. As seções a seguir mostram como criar uma política temporal e analisar padrões comuns que você pode expressar.

Crie uma política temporal

Você cria uma política temporal com a create-policy operação, a mesma operação usada para outras políticas, e a anexa a um mecanismo de política. A declaração de uma política temporal é inferior policy na definição, e não abaixo cedar de uma política de cedro apátrida.

O exemplo de AWS CLI a seguir cria uma política temporal em um mecanismo de políticas:

aws bedrock-agentcore-control create-policy \
  --policy-engine-id my-policy-engine-id \
  --name TransferToLookedUpAccount \
  --validation-mode FAIL_ON_ANY_FINDINGS \
  --definition '{
    "policy": {
      "statement": "permit (principal, action == AgentCore::Action::\"FundsTarget___transfer_funds\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway\") when temporal { formerly within 1h AgentCore::Action::\"FundsTarget___get_account_balance\"::response{ eventResource: resource, output.accountId: context.input.toAccount } };"
    }
  }'

Você também pode criar uma política temporal descrevendo-a em linguagem natural em vez de escrever você mesmo a declaração de Dogwood.

Esquema de eventos: campos que você pode referenciar

As condições dentro de um temporal { } bloco usam predicados de eventos temporais para corresponder a eventos específicos que foram registrados na sessão até o momento (incluindo a ação que está sendo autorizada no momento). Um predicado nomeia uma janela de tempo, um tipo de ação e evento e um conjunto de restrições de campo no evento correspondente. O create-policy exemplo na seção anterior usou um predicado,formerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource, output.accountId: context.input.toAccount }, que corresponde a um get_account_balance response registrado na última hora, que output.accountId é igual ao da solicitação atual. toAccount

Para escrever um predicado, você precisa saber quais eventos uma ação produz e quais campos cada evento carrega, porque esses são os campos que um predicado pode restringir e correlacionar. Esta seção descreve esse esquema de eventos.

Cada ação produz até três tipos de evento, nomeados de acordo com o tipo de evento no predicado (::request,::response,::error):

O esquema de eventos temporais define esses eventos para cada açãoA. …​inputs(A)e …​outputs(A) expanda para os campos de entrada e saída declarados da ação:

// Recorded for each authorized request.
decision event <A>::request {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the tool returns successfully; carries inputs and outputs.
event <A>::response {
    ...inputs(A),
    ...outputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the request is denied or the tool returns an error; history-only.
event <A>::error {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

Dentro de um corpo de predicado, você pode referenciar os seguintes campos do evento correspondente:

Para correlacionar um evento registrado com a solicitação atual, compare um desses campos com um valor da solicitação atual, comocontext.input.<name>.

Casos de uso

A seguir estão alguns exemplos de políticas temporais.

Ferramentas disponíveis

Os exemplos nesta seção usam um destino de gateway chamado FundsTarget que expõe três ferramentas. Em uma política, cada ferramenta é referenciada pelo nome da ação e pelos campos de entrada e saída listados aqui. FundsTarget___<tool-name>

Exemplo: integridade de saída para entrada

Esse exemplo permite que um agente transfira fundos somente para uma conta que ele consultou anteriormente na mesma sessão, impedindo que ele transfira para uma conta fabricada por ele. A política transfer_funds só é permitida quando uma get_account_balance resposta no início da sessão retornou a mesma conta:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{
        eventResource: resource,
        output.accountId: context.input.toAccount
    }
};

O ::response predicado corresponde à resposta registrada de um anteriorget_account_balance. output.accountIdé um campo que a ferramenta retorna e context.input.toAccount é a conta de destino na transfer_funds solicitação atual; exigir que eles sejam iguais vincula a transferência para uma pesquisa anterior.

Como um mecanismo de política nega por padrão e como uma ação é registrada response somente se for permitida, você também concede um simples permit para get_account_balance que a pesquisa seja permitida e registrada como uma resposta na sessão:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
);

Com as duas políticas em vigor, as solicitações em uma sessão são decididas da seguinte forma:

Exemplo: sequenciamento de ferramentas

Esse exemplo permite uma ação somente após uma ação de pré-requisito ser executada mais cedo na mesma sessão. A política a seguir get_account_balance só é permitida se uma transfer_funds solicitação ocorrer nos últimos cinco minutos:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___transfer_funds"::request{
        eventResource: resource
    }
};

O ::request predicado corresponde a uma transfer_funds solicitação anterior na sessão. Combine isso com um permit for transfer_funds para que a ação seja permitida e registrada. Com as duas políticas em vigor, get_account_balance é negado transfer_funds até que a seja executado na sessão:

Exemplo: atualização de dados

Este exemplo permite uma ação somente se um pré-requisito for concluído com êxito em uma janela restrita, de forma que resultados obsoletos expirem a permissão. Permite get_account_balance somente se for transfer_funds concluído nos últimos cinco minutos:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___transfer_funds"::response{
        eventResource: resource
    }
};

A correspondência em ::response vez de ativada ::request é a diferença do sequenciamento de ferramentas: um response evento é registrado somente quando a ação é concluída com êxito, portanto, essa política exige uma conclusão bem-sucedida recente, não apenas uma solicitação prévia. O comprimento da janela define o quão recente essa conclusão deve ser; quando a janela passa, a permissão caduca até que o pré-requisito seja executado novamente.

Exemplo: limitação de taxa baseada em sessões

Este exemplo limita uma ferramenta a um número fixo de chamadas em uma sessão. A política a seguir proíbe transfer_funds uma vez que ela tenha sido chamada mais de três vezes em cinco minutos na sessão:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource } && tp(t)))) == n
        && n > 3
};

A count expressão conta as transfer_funds solicitações registradas na sessão nos últimos cinco minutos, incluindo a solicitação atual; quando essa contagem excede três, a proibição se aplica. Emparelhe-o com um permit transfer_funds para que as chamadas sejam permitidas até o limite. Com as duas políticas em vigor, as três primeiras transfer_funds chamadas em qualquer janela de cinco minutos são permitidas e a quarta (ou posterior) chamada nessa janela é negada.

Exemplo: aprovação de uso único

Esse exemplo torna cada aprovação válida para um único uso. A transfer_funds é permitido somente se nenhum transfer_funds tiver sido concluído desde a mais recente get_account_balance (a aprovação) na sessão. Quando a transferência é concluída, ela consome a aprovação e a próxima transferência é negada até que uma nova aprovação ocorra:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    !AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
    since within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Essa since condição é válida quando uma conclusão get_account_balance (a aprovação) ocorreu na última hora e nenhuma conclusão transfer_funds ocorreu desde aquela aprovação. A correspondência ::response é essencial: uma transferência conta como concluída somente depois de bem-sucedida, portanto, a solicitação autorizada não se bloqueia sozinha. Combine isso com um formulário permit para get_account_balance que as aprovações sejam registradas.

As solicitações em uma sessão são decididas da seguinte forma:

Exemplo: orçamento cumulativo

Este exemplo limita o valor total de uma ação em uma janela. A política a seguir proíbe transfer_funds quando a soma da amount entrada nas transferências da sessão nos últimos cinco minutos atinge 3000:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource, input.amount: amt } && tp(t)))) == total
        && total >= 3000
};

A sum expressão soma o campo amount de entrada nas transfer_funds solicitações correspondentes na janela, incluindo a solicitação atual; quando o total atinge o limite, a proibição se aplica. O campo somado é um campo de entrada da ação. Combine a política com um permit paratransfer_funds. Por exemplo, com um limite de 3000 e transferências de 1000, os dois primeiros são permitidos e o terceiro, que chegaria a 3000, é negado.

Assim como acontece com a limitação de taxa, a soma tem como escopo a sessão atual e não é agregada entre as sessões.

Exemplo: resfriamento

Este exemplo impõe um resfriamento: uma ação não pode ser repetida dentro de um período fixo de sua última conclusão. Ele proíbe transfer_funds se for transfer_funds concluído no último minuto:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1m AgentCore::Action::"FundsTarget___transfer_funds"::response{
        eventResource: resource
    }
};

Essa condição é autorreferencial: corresponde à mesma ação que está sendo autorizada. A correspondência ::response é o que faz com que funcione, porque a solicitação autorizada ainda não produziu uma resposta, portanto, ela não corresponde a si mesma. A correspondência ::request aqui faria com que a solicitação atual correspondesse ao seu próprio evento, e a ação seria permanentemente proibida. Depois que a janela terminar sem nenhuma nova conclusão, a ação será permitida novamente.

Exemplo: pré-condição contínua

Este exemplo permite uma ação somente enquanto uma pré-condição for válida: uma confirmação positiva ocorreu recentemente e nada a invalidou desde então. É permitido transfer_funds somente se uma get_account_balance (a confirmação) for concluída nos últimos cinco minutos e nenhuma get_transaction_history (a invalidação) tiver sido concluída desde:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    !AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Essa since condição é válida quando uma conclusão get_account_balance ocorreu nos últimos cinco minutos e nenhuma conclusão get_transaction_history ocorreu desde então. O preenchimento get_account_balance confirma a pré-condição e exigir que nada get_transaction_history tenha acontecido desde então garante que nada a invalidará posteriormente. Conceda licenças para ambos get_account_balance e get_transaction_history assim eles são registrados.

Exemplo: cadeia multi-hop

Você pode criar várias políticas de sequenciamento para exigir uma cadeia de ações, cada uma permitida somente após a conclusão da anterior. Este exemplo requer a cadeia get_account_balance → get_transaction_history →transfer_funds, usando duas políticas (uma por link):

// Link 1: permit get_transaction_history only after get_account_balance completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

// Link 2: permit transfer_funds only after get_transaction_history completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Cada política impõe um elo, e a cadeia emerge de sua composição: transfer_funds exigeget_transaction_history, o que exige. get_account_balance Conceda um permit para a primeira ação na cadeia para que ela possa começar. Uma tentativa fora de ordem é negada até que seu pré-requisito seja concluído.

Exemplo: exclusão mútua

Esse exemplo torna duas ações mutuamente exclusivas em uma janela: a que for executada primeiro bloqueia a outra. Ele usa duas políticas de proibição simétricas para que a exclusão seja válida em ambas as direções. Aqui, transfer_funds e ambas get_transaction_history não podem ocorrer em dois minutos:

// Forbid get_transaction_history if a transfer_funds was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource }
};

// Forbid transfer_funds if a get_transaction_history was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___get_transaction_history"::request{ eventResource: resource }
};

Como cada política é compatível::request, até mesmo a solicitação de uma ação bloqueia a outra — o bloqueio não espera que a primeira ação seja concluída. Você precisa de duas forbid políticas simétricas, uma por direção: uma proíbe get_transaction_history após uma transfer_funds solicitação e a outra proíbe transfer_funds após uma solicitação. get_transaction_history Uma única proibição bloquearia apenas um pedido. Combine ambos com permissões para as duas ações.

Exemplo: combinação de condições temporais, de guardrail e de cedro

Uma única política pode combinar uma condição temporal com as condições padrão de proteção e cedro; todas elas devem ser satisfeitas para que a política seja aplicada. Esse exemplo transfer_funds só é permitido quando o valor da transferência cumulativa permanece abaixo de um limite (temporal), a solicitação não contém informações confidenciais (guardrail) e o chamador não está em um grupo bloqueado (Cedar):

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource, input.amount: amt } && tp(t)))) == total
        && total < 60000
}
when {
    BedrockGuardrails::SensitiveInformation(["ACCOUNT_NUMBER"], [context.input.body]).count() == 0
}
unless {
    principal in Group::"blocked_users"
};

O bloco temporal impõe o limite cumulativo, o bloco de proteção bloqueia as solicitações que contêm as informações confidenciais listadas e o bloco Cedar unless exclui os principais bloqueados. Cada tipo de condição é avaliado de forma independente e a permissão se aplica somente quando todas elas são válidas. Para a sintaxe da condição do guardrail, consulte Guardrails in policies; o bloco temporal se comporta conforme descrito nos exemplos anteriores.

Exemplo: pré-requisitos paralelos

Este exemplo exige que dois pré-requisitos sejam concluídos, em qualquer ordem, antes que uma ação seja permitida. É permitido get_account_balance somente se ambos transfer_funds e for get_transaction_history concluído na última hora, combinando duas formerly condições com&&:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Ambos os pré-requisitos devem ter sido preenchidos (::response) dentro da janela, e a ordem não importa. Conceda licenças para ambas as ações de pré-requisito para que elas sejam registradas. Completar apenas uma deixa a ação negada até que a outra também seja concluída.

Exemplo: limite de aprovação

Este exemplo permite uma ação somente após um número limite de eventos de qualificação. Isso só é permitido get_account_balance para um cliente se pelo menos duas forem transfer_funds preenchidas na conta desse cliente, correlacionando a transferência toAccount com a solicitação de saldo: customerId

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource, input.toAccount: context.input.customerId } && tp(t)))) == n
        && n >= 2
};

A count expressão conta os eventos concluídos correspondentes na janela e a ação é permitida quando a contagem atinge o limite.

Exemplo: bloquear uma ação após uma negação anterior

Este exemplo bloqueia uma ação confidencial quando uma chamada de ferramenta anterior na mesma sessão foi negada. Uma solicitação negada é registrada como um error evento e o ::error predicado corresponde a esse evento. A política a seguir proíbe transfer_funds sempre que uma get_account_balance sessão seja negada nos últimos três minutos:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 3m AgentCore::Action::"FundsTarget___get_account_balance"::error{
        eventResource: resource
    }
};

Uma forbid regra substitui qualquer umapermit, então combine-a com uma permit que permita transfer_funds em condições normais:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
);

Com as duas políticas em vigor, as solicitações em uma sessão são decididas da seguinte forma: