Exemplos de políticas temporais

As políticas desta seção decidem com base no que já aconteceu anteriormente na mesma sessão. Eles permitem que você exija uma aprovação antes de um pagamento, expire uma permissão obsoleta, limite um total contínuo ou bloqueie uma ação após uma falha. Nenhuma solicitação contém informações suficientes para decidir qualquer uma delas.

Cada exemplo autoriza o gateway de referência descrito em Configuração de recursos para obter exemplos. Para o esquema de eventos temporais, os operadores, os IDs de sessão, as cotas e a disponibilidade da região, consulte Políticas temporais e Criação de políticas temporais.

Antes de usar esses exemplos

Quatro coisas determinam se uma política temporal se comporta da maneira que você espera.

É necessário um ID de sessão

O histórico temporal tem como escopo uma sessão que você nomeia. Envie uma ID de sessão no x-amzn-bedrock-agentcore-policy-session-id cabeçalho em cada solicitação, começando pela primeira. O gateway não gera uma para você e, se o mecanismo tiver uma política temporal, uma solicitação sem ID de sessão falhará na validação.

Somente ações permitidas se tornam response eventos

Uma ação registra um response evento somente se uma política permitir e for concluída. Em vez disso, uma ação negada registra um error evento. Portanto, cada um dos exemplos a seguir também precisa de um plano permit para a ação de pré-requisito — caso contrário, o pré-requisito será negado, nunca registrado como um response e a condição temporal nunca poderá corresponder. Cada exemplo indica o que permite emparelhá-lo com.

eventResource: resourceé obrigatório

Cada predicado deve incluireventResource: resource, o que vincula o evento correspondente ao recurso no escopo da política. Omiti-lo é rejeitado com. temporal predicates do not constrain the matched event to the current request’s resource Você não precisa escrever sessionId — o esquema do evento já define o escopo de cada predicado até a sessão atual.

As comparações ordenadas precisam de números inteiros; a igualdade não

Dentro de um temporal { } bloco, os dois tipos de comparação aceitam tipos diferentes.

• Pedir —<,, ⇐>, >= — requer um integer em ambos os lados. A decimal ou a string é rejeitado quando você cria a política, comcomparison requires numeric operands on both sides.

• A igualdade — == e != — funciona em qualquer tipo, desde que os dois lados sejam do mesmo tipo. Isso é o que a correlação usa: a correspondência com input.claimId context.input.claimId compara duas strings, o que é suportado.

Portanto, modele qualquer valor que uma política temporal tenha para totalizar ou limitar como uminteger. É por isso que o gateway de referência indica dinheiro em unidades inteiras menores nas ferramentas que esses exemplos agregam. A soma tem o mesmo requisito e sua própria mensagem: sum precisa de uma integer convocação. Para obter mais informações, consulte Tipos de parâmetros em condições.

Exigir uma aprovação prévia para a mesma reclamação

Intenção: permitir que um pagamento seja desembolsado somente para uma reclamação que foi aprovada no início da sessão, para que o agente não possa desembolsar com base em um ID de reclamação que ele inventou.

O ::response predicado corresponde a um preenchidoapprove_claim. Correlacioná-la output.claimId com a solicitação atual context.input.claimId é o que vincula o desembolso a essa aprovação específica — sem a correlação, qualquer aprovação na sessão autorizaria o pagamento de qualquer reclamação.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{
        eventResource: resource,
        output.claimId: context.input.claimId
    }
};

Importante

output.*os campos existem em um response evento somente quando o destino declara um esquema de saída para a ferramenta. Muitos destinos não o fazem — um alvo Lambda, por exemplo, geralmente declara somente entradas e, em seguida, o evento carrega apenaseventPrincipal,,eventResource, e. input.* requestId sessionId

Se você nomear um campo que o evento não declara, o serviço rejeitará a política e o erro listará o que está disponível:

predicate `AgentCore::Action::"MyTarget___verify_purchase"::response` mentions field
`output.orderId`, which is not declared on that event (declared fields: eventPrincipal,
eventResource, input.orderId, requestId, sessionId)

Use essa lista para ver o que você pode correlacionar. Quando não houver campo de saída, correlacione em um campo de entrada compartilhado — input.claimId: context.input.claimId vincule as duas chamadas à mesma declaração sem precisar que a ferramenta anterior retorne nada.

Os dois não são equivalentes, então escolha deliberadamente. Uma correlação de entrada corresponde ao que a chamada anterior solicitou; uma correlação de saída corresponde ao que ela retornou. Se sua regra depender de um valor produzido pela ferramenta anterior — um ID de aprovação, um valor calculado — somente uma correlação de saída a aplica, e isso exige que o alvo declare um esquema de saída.

Combine isso com uma licença simples para que as aprovações sejam permitidas e registradas:

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

Sequência de solicitações em uma sessão	Decisão
disburse_paymentsem aprovação prévia	DENY
approve_claimpara uma reclamação e, em seguida, disburse_payment para a mesma reclamação	PERMISSÃO
approve_claimpara uma reivindicação e, em seguida, disburse_payment para uma reivindicação diferente	DENY

Exigir uma ação de pré-requisito

Intenção: permitir que uma reivindicação seja aprovada somente depois que alguém consultou seu status na sessão.

Combinação ::request significa que o pré-requisito só precisa ter sido tentado, não ter sido bem-sucedido. Combine com uma licença paraget_claim_status.

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

Exigir um bem-sucedida pré-requisito, recentemente

Intenção: permitir aprovação somente se uma pesquisa de status for concluída nos últimos cinco minutos, para que uma pesquisa obsoleta pare de conferir permissão.

A única alteração em relação ao exemplo anterior está ::response no lugar de::request, e é a diferença entre “foi tentada” e “foi bem-sucedida”. O tamanho da janela define o quão recente esse sucesso deve ser; uma vez aprovado, a permissão expira até que o pré-requisito seja executado novamente.

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

Sequência de solicitações em uma sessão	Decisão
approve_claimantes de qualquer pesquisa concluída	DENY
a pesquisa é concluída e, em seguida, approve_claim dentro da janela	PERMISSÃO
approve_claimdepois que a janela passar	DENY

Limite quantas vezes uma ação é executada

Intenção: permitir no máximo três desembolsos em qualquer período de cinco minutos de uma sessão.

countconta os eventos correspondentes na janela, incluindo a solicitação que está sendo autorizada, então a quarta chamada em uma janela é a primeira a ser negada. O exists (n: Long) fichário captura a contagem para que o n > 3 filtro possa testá-la; o agregado precisa de parênteses à esquerda de. == Emparelhe com uma permissão disburse_payment para que as chamadas sejam permitidas até o limite.

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

Importante

Isso não é um controle de segurança. O chamador fornece o ID da sessão, para que ele possa redefinir a contagem iniciando uma nova sessão. Use-o para moldar o comportamento em uma sessão cooperativa — para interromper um agente em loop, por exemplo — e não para impor um limite a um chamador que controla sua própria ID de sessão. Para obter mais informações, consulte Considerações de segurança.

Limite um total contínuo

Intenção: permita os desembolsos até que totalizem 3.000,00 em cinco minutos e, em seguida, pare.

sumadiciona o campo de entrada nomeado nos eventos correspondentes, incluindo a solicitação atual, para que uma solicitação que ultrapasse o limite seja negada. Com um limite de 300.000 centavos e desembolsos de 100.000, os dois primeiros são permitidos e o terceiro é negado.

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

O domínio de duas variáveis,for (amt: Long), (t: Timepoint), é obrigatório: é o valor que amt está sendo somado e t distingue os pontos de tempo; portanto, dois desembolsos do mesmo valor são contados duas vezes em vez de serem desduplicados em um.

nota

amountCentsestá integer no esquema da ferramenta, e é isso que faz essa política funcionar. A sum agregação precisa de uma soma de números inteiros, e a comparação de ordenação total precisa de um número inteiro em ambos os lados. Portanto, um campo que seu esquema declara como não pode gerar um number limite como esse. Para as regras de tipo das quais esses exemplos dependem, consulte Antes de usar esses exemplos.

Faça com que cada aprovação seja válida para um uso

Intenção: permitir um desembolso por aprovação. Depois de um pagamento, exija uma nova aprovação.

O since operador segura quando a âncora à sua direita ocorreu dentro da janela e a condição à sua esquerda se manteve continuamente desde então. Aqui está escrito: uma aprovação foi concluída na última hora e nenhum desembolso foi concluído desde então. O primeiro pagamento após uma aprovação o consome.

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

Combinar ::response no lado negativo é essencial. A solicitação que está sendo autorizada ainda não produziu uma resposta, então ela não se bloqueia. Combinar isso faria com ::request que cada desembolso se negasse.

Sequência de solicitações em uma sessão	Decisão
approve_claim, então disburse_payment	PERMISSÃO
um segundo disburse_payment sem nova aprovação	DENY
um novoapprove_claim, então disburse_payment	PERMISSÃO

nota

Um response evento é gravado logo após a conclusão da chamada. Aguarde a devolução da aprovação antes de emitir o desembolso, em vez de enviá-la consecutivamente. Para obter mais informações, consulte Ações de sequenciamento que dependem de uma resposta anterior.

Imponha um resfriamento

Intenção: evitar que a mesma ação se repita dentro de um minuto após a conclusão.

Essa condição se refere à mesma ação que ela autoriza. ::responseé o que torna isso seguro: a solicitação atual ainda não tem resposta, então ela não corresponde a si mesma. Escrita com::request, a solicitação atual corresponderia ao seu próprio evento e a ação seria proibida permanentemente. Para obter mais informações, consulte Self-referential as condições, incluindo a solicitação atual.

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

Exigir uma condição prévia que não tenha sido invalidada

Intenção: permitir o desembolso enquanto a aprovação estiver em vigor e retirar a permissão se a solicitação for reaberta para análise de status posteriormente.

Ela tem o mesmo formato da aprovação de uso único, mas a ação negada é diferente da ação que está sendo autorizada, o que transforma “consumir a aprovação” em “invalidar a aprovação”. Conceda licenças para ambos approve_claim e. get_claim_status

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    !AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Sequência de solicitações em uma sessão	Decisão
disburse_paymentantes de qualquer aprovação	DENY
approve_claim, então disburse_payment	PERMISSÃO
get_claim_statusocorre, então disburse_payment	DENY
um novoapprove_claim, então disburse_payment	PERMISSÃO

Exigir uma cadeia de ações em ordem

Intenção: Exija a pesquisa do status da sequência, depois a aprovação e, em seguida, o desembolso.

Uma política por link, e a cadeia emerge de sua composição. Conceda uma permissão simples para a primeira ação para que a cadeia possa começar. Uma tentativa de falha na etapa é negada até que seu pré-requisito seja concluído.

// Link 1: approve only after a completed status lookup
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
};

// Link 2: disburse only after a completed approval
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Exija dois pré-requisitos em qualquer ordem

Intenção: permitir o desembolso somente após a conclusão da pesquisa de status e da aprovação, em qualquer ordem.

Duas formerly condições unidas && exigem ambas e nenhuma restringe a ordem. Isso usa dois dos três operadores temporais que uma única política pode conter.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Faça duas ações mutuamente exclusivas

Intenção: em dois minutos, permita o desembolso ou a exclusão de uma reclamação, mas não ambas.

A exclusão precisa de duas políticas simétricas, uma por direção; uma única forbid bloquearia apenas um pedido. Combinar ::request significa simplesmente tentar uma ação para bloquear a outra, sem esperar que ela seja concluída.

// Forbid deletion if a disbursement was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___delete_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource }
};

// Forbid disbursement if a deletion was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___delete_claim"::request{ eventResource: resource }
};

Exigir um número limite de eventos

Intenção: permitir que uma reclamação seja excluída somente após pelo menos dois desembolsos concluídos contra ela.

A correlação input.claimId com a reivindicação da solicitação atual define o escopo da contagem dessa solicitação em vez de contar cada desembolso na sessão.

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

nota

countconta eventos, não chamadores distintos. Não pode expressar “aprovado por duas pessoas diferentes”, porque nada impede que um diretor produza todos os eventos correspondentes. Para aprovação multipartidária, correlacione eventPrincipal ou imponha a distinção fora da política.

Bloquear uma ação após uma negação anterior

Intenção: interromper o desembolso de uma sessão depois que qualquer tentativa de aprovação for negada.

Um error evento registra uma solicitação que foi negada ou que falhou, assim ::error como uma política reage a uma falha anterior. Combine isso com uma licença simples disburse_payment para que seja permitido em condições normais.

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

Esse é um padrão de contenção útil: um agente que está investigando as permissões que não tem é excluído da ação confidencial em vez de poder continuar tentando.

Combine condições temporais, de proteção e de solicitação

Intenção: permitir que um chamador registre reivindicações, desde que a sessão tenha menos de três registros nas últimas 24 horas, a descrição da reclamação não contenha detalhes bancários e o chamador não tenha uma função restrita.

Todos os três tipos de condições se compõem em uma política, e cada cláusula deve ser válida para que a permit seja aplicada. O temporal bloco impõe o limite, o when bloco filtra o conteúdo e o unless bloco exclui uma função. Cada um é avaliado de forma independente.

permit (
    principal is AgentCore::OAuthUser,
    action == AgentCore::Action::"InsuranceAPI___file_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"InsuranceAPI___file_claim"::request{ eventResource: resource } && tp(t)))) == n
        && n <= 3
}
when {
    BedrockGuardrails::SensitiveInformation(["US_BANK_ACCOUNT_NUMBER"], [context.input.description]).count() == 0
}
unless {
    principal.hasTag("role") &&
    principal.getTag("role") == "restricted"
};

As telas de proteçãodescription, que são o único parâmetro de texto livre usado. file_claim Aponte uma grade de proteção de informações confidenciais para um campo que possa conter de forma plausível os dados que você está examinando. Se você apontar para um identificador ou número, não há nada para detectar e a cláusula será aprovada silenciosamente. descriptioné opcional, portanto, uma solicitação que a omite não fornece texto à grade de proteção e a cláusula é válida.

O que muda quando você edita uma política temporal

Adicionar ou atualizar uma política temporal em um mecanismo invalida as sessões temporais abertas desse mecanismo, porque o histórico registrado não corresponde mais às regras que estão sendo aplicadas a ele. A próxima solicitação que reutiliza uma sessão invalidada falha com HTTP 409. ConflictException Inicie uma nova sessão e tente novamente; a nova sessão começa com um histórico vazio e é avaliada em relação às políticas atualizadas.

Importante

Planeje isso ao implementar uma mudança temporal na política. Os clientes precisam tratar a 409 como “iniciar uma nova sessão”. Qualquer fluxo de trabalho em várias etapas em andamento é reiniciado em vez de ser retomado.