Agentes de IA não estão prontos para produção - e controle de acesso pode ser a razão

-Daniel Bass

Melhorar o desempenho da aplicação através do uso de agentes de IA está se tornando uma prática muito comum - seja devido ao hype em toda a indústria ou casos de uso úteis reais.

Esses agentes de IA, no entanto, muitas vezes exigem acesso a dados altamente sensíveis, introduzindo riscos significativos de segurança.Sem soluções padronizadas de controle de acesso, as equipes de desenvolvimento muitas vezes construem medidas de segurança do zero - levando a casos em queAssistentes expõem informações sensíveis do pacientee vários agentes AI sendo comprometidos através deAtaques de Injeção Rápida. o

Proteger os agentes de IA neste contexto está se tornando tão importante quanto as capacidades dos próprios agentes de IA - se não mais.

Para solucionar este problema, aPermissão.euhá algum tempo trabalhando em uma abordagem de segurança estruturada que gostaria de apresentar-lhe hoje:

The Four-Perimeter Framework. o

Este método fornece uma estratégia abrangente para proteger os agentes da IA através da implementaçãoControle de acesso de grãos finos, assegurando a conformidade, e mitigando potenciais vetores de ataque. Antes de entrar na solução, vamos falar mais sobre o espaço do problema.

O problema: riscos de segurança de IA em domínios sensíveis

Medidas tradicionais de segurança de aplicativos e mecanismos de controle de acesso faltam quando se trata de lidar com agentes de IA.Controle de acesso baseado em funções (RBAC)Excel na gestão de permissões estáticas, eles lutam com a natureza dinâmica das respostas de IA. Ao contrário das aplicações tradicionais onde os mapas de entrada para saídas previsíveis e padrões de acesso são bem definidos, a IA gera respostas únicas para cada consulta.

A forma como os sistemas de IA acessam os dados também não se encaixa nos padrões de segurança.Para fornecer respostas precisas e úteis, os agentes de IA precisam de um amplo acesso a várias fontes de dados e bases de conhecimento.O RBAC clássico prova ser muito rígido para essa necessidade - você não pode simplesmente atribuir permissões estáticas quando os requisitos de dados mudam com base no contexto.Baseado em atributosA abordagem que pode tomar decisões de acesso dinâmico.

Outra preocupação é os novos vetores de ataque que os sistemas de IA introduzem. as medidas de segurança convencionais não foram projetadas para lidar com ataques de injeção rápida, tentativas de extração de modelos ou ataques de envenenamento de dados.

A solução vem na forma de uma estrutura de segurança abrangente construída em torno de quatro perímetros essenciais -

A solução: o quadro de quatro perímetros

Como os aplicativos de IA diferem do software padrão em como eles processam entradas, recuperam dados, executam ações e geram saídas, eles também introduzem riscos de segurança únicos.Para enfrentar esses desafios, precisamos de uma abordagem de segurança estruturada que aplique controle de acesso em todas as fases da interação de IA. E isso é exatamente o que eu quero mostrar aqui:

OFour-Perimeter Frameworké projetado para fazer valer a consciência da identidade,autorização de grãos finos ao longo do ciclo de vida da AIEle introduz limites de segurança que regem quais modelos de dados de IA podem acessar, quais operações eles podem executar e como suas respostas são validadas.

O quadro consiste em quatro partes:

Não
1. Filtragem prompt – Garantir que apenas entradas seguras e validadas alcancem modelos de IA.
Não
2. RAG Data Protection – Controle do acesso da IA a fontes externas de conhecimento.
Não
3. Secure External Access – Definir permissões de agente de IA ao interagir com ferramentas externas.
Não
4. Response Enforcement – Aplicando verificações de conformidade e filtrando saídas geradas por IA.
Não

Ao aplicarfine-grained access control (FGA)Os princípios sobre esses perímetros, os agentes da IA permanecemsecure, auditable, and compliantsem sacrificar sua flexibilidade e funcionalidade.

Onde o FGA entra?

Como mencionado anteriormente, os métodos tradicionais de controle de acesso, como o RBAC, não conseguem lidar com o comportamento dinâmico e contextualmente dependente da IA. É aqui que entra em jogo a autorização de grãos finos (FGA), especificamente através do controle de acesso baseado em atributos (ABAC) e do controle de acesso baseado em relacionamento (ReBAC):

Não
• Os modelos de IA processam entradas não estruturadas, o que dificulta a aplicação de regras tradicionais de segurança.A ABAC resolve isso extraindo atributos estruturados de prompts de IA e usando-os em decisões de acesso baseadas em políticas.
Não

Não
• O ReBAC for RAG Data Protection Retrieval-Augmented Generation (RAG) permite que modelos de IA extraam informações de bancos de dados vetoriais. O ReBAC fornece uma maneira natural de reforçar a segurança nesta configuração, definindo relações entre usuários, fontes de dados e agentes de IA. Em vez de atribuir permissões estáticas, o ReBAC concede ou nega o acesso dinamicamente com base em como os objetos de dados se relacionam uns com os outros – permitindo permissões de recuperação conscientes do contexto.
Não

Ao combinar ABAC e ReBAC, as aplicações de IA ganham mecanismos de controle de acesso flexíveis e orientados por políticas que se adaptam a diferentes fluxos de trabalho de IA sem exigir intervenção manual.

Como é uma implementação passo a passo?

Vamos passar por uma implementação prática para ver oFour-Perimeter Framework in actionEste exemplo assegura que um agente devalidating prompts, enforcing data protection, restricting external access, and moderating responsesLevantamentoPermissão.eu AI Access Control integrations at each step.

1. Implement Prompt Filtering

O primeiro perímetro de segurança centra-se na validação e sanitização das entradas de IA antes que elas cheguem ao modelo.

Não
• Os controles de autorização são incorporados no pipeline de validação instantânea, impedindo que dados não autorizados influenciem as saídas de IA.
Não
• O controle de acesso baseado em funções, atributos e relações é aplicado, garantindo que apenas os parâmetros aprovados passem para a IA.
Não
• Todas as violações de políticas são registradas e bloqueadas em tempo real, preservando um rastro auditável de decisões de acesso.
Não

Aqui estão os três métodos para filtrar prompts - do mais fácil ao mais avançado:

Não
1. Validação de token - Um método eficiente para verificações simples, como comprimento de prompt ou permissão geral de entrada em execução no sistema.
Não
2. Correspondência de padrão - neste método, o controle de permissão examina padrões no texto do prompt. Verificar, por exemplo, se o padrão corresponde a uma consulta SQL ou exemplo de código.
Não
3. Classificação de IA - o método mais avançado nesta lista, a classificação de IA usa a IA para analisar o prompt usando um prompt de sistema dedicado, classificando-o em uma entrada estruturada que pode ser analisada com precisão na verificação de permissões.
Não

Prompt Filtering with PydanticAI

Para melhor demonstrar a implementação de filtragem de prompt eficiente, aqui está um exemplo de usar as ferramentas PydanticAI para filtrar as entradas do usuário para os agentes de IA. PydanticAI é uma estrutura de agentes que aproveita a famosa biblioteca Pydantic de Python e suas capacidades de digitação estática e a transforma em uma estrutura de IA estruturada que lida com dados não estruturados.

O seguinte repositório do GitHub contém uma implementação completa do framework para PydanticAI:github.com/permitio/permit-pydanticai

@financial_agent.tool
async def validate_financial_query(
    ctx: RunContext[PermitDeps],
    query: FinancialQuery,
) -> bool:
    """Key checks:
    - User has explicitly opted in to AI financial advice
    - Consent is properly recorded and verified
    - Classifies if the prompt is requesting advice

    Args:
        ctx: Context containing Permit client and user ID
        query: The financial query to validate

    Returns:
        bool: True if user has consented to AI advice, False otherwise
    """
    try:
        # Classify if the prompt is requesting advice
        is_seeking_advice = classify_prompt_for_advice(query.question)

        permitted = await ctx.deps.permit.check(
            # The user object with their attributes
            {
                "key": ctx.deps.user_id,
            },
            # The action being performed
            "receive",
            # The resource being accessed
            {
                "type": "financial_advice",
                "attributes": {"is_ai_generated": is_seeking_advice},
            },
        )

        if not permitted:
            if is_seeking_advice:
                return "User has not opted in to receive AI-generated financial advice"
            else:
                return "User does not have permission to access this information"

        return True

    except PermitApiError as e:
        raise SecurityError(f"Permission check failed: {str(e)}")

2. Enforce Data Protection –

Em seguida, garantimosretrieval-augmented generation (RAG)para garantir que os modelos de IA só possam acessarauthorized knowledge sourcesIsso pode ser alcançado através da filtragem finamente granulada dos dados do agente de IA em nome do usuário dentro do fluxo de trabalho de IA:

Não
• A política finamente granulada usa modelos avançados de filtragem de dados, como controle de acesso baseado em relacionamento, para permitir a filtragem avançada de consulta para o motor de políticas.
Não
• As fontes vetoriais e gráficas conectadas aos agentes de IA têm metadados que podem ajudar o motor a manipular a consulta não estruturada, filtrando-a para incluir apenas dados permitidos.
Não
• Cada vez que o agente obtém dados da base de conhecimento RAG, ele filtra os resultados por permissão do usuário.
Não

Quando o aplicativo do agente realiza a filtragem RAG, ele usa um dos seguintes métodos:

Não
• FilterObjects – Neste método, o aplicativo do gráfico obtém todos os dados relevantes do RAG e, em seguida, filtra-os por permissões de usuário.
Não
• GetUserPermissions - Neste método, o agente fornece à RAG uma consulta não estruturada. A RAG chama a função GetUserPermissions, anexando uma consulta de filtro à consulta RAG não estruturada.

RAG Data Protection with Langchain

Langchain, o famoso framework de aplicações de IA, é conhecido (também) por seus componentes de retriever que fornecem grande suporte em retrievers personalizados que podem ser montados com qualquer tipo de fonte de dados, tornando a implementação de RAG seguro fácil.SelfQueryRetriever, você pode envolver o RAG usual com umGetUserPermissionsAqui está um exemplo do PermitSelfQueryRetriever que obtém o usuário, a ação e o tipo de recursos RAG para filtrar os resultados para o LLM:

# 1. Build a small in-memory vector store
  embeddings = OpenAIEmbeddings()
  vectorstore = FAISS.from_documents(docs, embedding=embeddings)

# 2. Initialize the PermitSelfQueryRetriever
retriever = PermitSelfQueryRetriever(
    api_key=os.getenv("PERMIT_API_KEY", ""),
    pdp_url=os.getenv("PERMIT_PDP_URL"),
    user=USER,
    resource_type=RESOURCE_TYPE,
    action=ACTION,
    llm=embeddings,
    vectorstore=vectorstore,
    enable_limit=False,
)

O seguinte repositório contém a implementação completa do framework para Langchain:HTTPS://github.com/permitio/langchain-permit

3. Secure External Access –

Os agentes de IA muitas vezes interagem com APIs, serviços e ferramentas de automação externas. Sem controle de acesso adequado, eles correm o risco de executar ações não autorizadas.

Não
• Usar modelos como o MCP, que define um modelo servidor-cliente onde os agentes de IA interagem com serviços externos, é um grande passo para permitir a segurança para o acesso externo da IA (por exemplo, bancos de dados, APIs, sistemas de pagamento).
Não
• A infraestrutura de ação de IA pode usar um serviço como Permit.io para realizar verificações de autorização no nível de ação, verificando quem está fazendo uma solicitação e que ação eles querem realizar.
Não
• Os desenvolvedores são capazes de atribuir identidades de máquina a agentes de IA, limitando suas capacidades apenas a funções pré-aprovadas.
Não

Enquanto GPTs e interfaces de linguagem natural não são novas, deixá-los executar ações em nome dos usuários é um desafio relativamente novo muitos engenheiros lutam com. Podemos notar três níveis distintos de controle de acesso importante para garantir aqui:

Não
1. Um usuário pede a um agente de IA para executar uma operação, como uma chamada HTTP. O agente de IA sabe verificar se a operação é permitida, considerando o contexto atual e o usuário.
Não
2. Comunicação agente-a-agente - neste próximo nível, exigimos um fluxo em cascata de identidades e permissões que permitam que os agentes realizem suas próprias ações com base no princípio do menor privilégio.
Não
3. Fluxos de solicitação de acesso - o nível mais emocionante de acesso externo é quando o agente de IA entende a necessidade de solicitar acesso diretamente de um usuário humano quando quer executar uma operação.
Não

MCP, Human-in-the-Loop, and External Access

Model Context Protocol é um novo protocolo introduzido pela Anthropic, que resolve o problema de permitir que os agentes de IA realizem ações proativas e serve como o maior facilitador para garantir o acesso externo.

No exemplo a seguir, mostramos um servidor MCP que sabe como gerenciar fluxos de solicitações de acesso, trazendo humanos para o loop e usando as APIs do Permit.io para solicitar permissões.

Você pode ver o exemplo de código completo para o servidor de solicitação de acesso do MCP aqui:HTTPS://github.com/permitio/permit-mcp

@mcp.tool()
async def request_access(username: str, resource: str, resource_name: str) -> dict:
  """
  Initiate access request call to a specific resource in the system

  Args:
    username: The username of the person requesting access
    resource: The resource type the user is request access for
    resource_name: The name of the restaurant to request access for

  """
  
  login = await permit.elements.login_as({ "userId": slugify(username), "tenant": "default"})
  print(login)
  
  url = f"https://api.permit.io/v2/facts/{PROJECT_ID}/{ENV_ID}/access_requests/{ELEMENTS_CONFIG_ID}/user/{slugify(username)}/tenant/default"
  payload = {
      "access_request_details": {
          "tenant": "default",
          "resource": resource,
          "resource_instance": resource_name['id'],
          "role": "viewer",
      },
      "reason": f"User {username} requests role 'viewer' for {resource_name}"
  }
  headers = {
      "authorization": "Bearer YOUR_API_SECRET_KEY",
      "Content-Type": "application/json",
  }
  async with httpx.AsyncClient() as client:
      await client.post(url, json=payload, headers=headers)
      return "Your request has been sent. Please check back later."

4. Validate AI Responses –

O perímetro final impõe moderação de conteúdo e conformidade em respostas geradas por IA. Isso pode ser feito criando um fluxo de trabalho que aplica filtragem baseada em políticas antes de entregar saídas de IA:

Não
• Uma verificação de permissão pode ser adicionada ao aplicativo do agente, permitindo a aplicação de políticas em cada etapa da cadeia antes que o usuário realmente receba uma resposta.
Não
• Fluxos de trabalho de validação de dados e autorização combinados garantem que apenas dados validados e permitidos possam avançar.
Não
• A resposta que retorna aos usuários pode ser editada com base em limitações predefinidas, permitindo assim a ocultação de dados ou notificando o usuário de limitações de uso.
Não

Response Filtering with Langflow

No exemplo a seguir, usamos o Langflow, um editor visual de aplicações AI sem código, para criar um componente de verificação de permissões que está posicionado antes de qualquer resposta de bate-papo para o usuário. Usando as capacidades de modelagem de fluxo amigável do LangFlow, você pode facilmente anexar outro componente que mascara detalhes indesejados nas respostas devolvidas.Este repositórioContém todos os componentes de controle de acesso necessários para aplicações seguras do Langflow.

CONCLUSÃO

Os sistemas de IA estão se integrando rapidamente em aplicações em todas as indústrias, mas seus quadros de segurança permanecem subdesenvolvidos em comparação com o software tradicional.Sem um controle de acesso adequado e consciente da identidade, os agentes de IA correm o risco de expor dados sensíveis, executar operações não autorizadas e gerar respostas que ficam fora das diretrizes de conformidade.

O Quadro de Quatro Perímetros oferece uma maneira estruturada de proteger os fluxos de trabalho de IA em todas as fases – desde a validação de prompts e a proteção de dados de geração aumentada por recuperação (RAG) até o controle de ações externas impulsionadas por IA e a aplicação da conformidade de resposta.Ao aproveitar a autorização de grãos finos (FGA) com ABAC e ReBAC, os desenvolvedores podem garantir que os agentes de IA permaneçam funcionais e seguros, adaptando-se dinamicamente a cenários de segurança do mundo real.

Em vez de construir controle de acesso a partir do zero, as integrações de controle de acesso de IA da Permit.io com PydanticAI, LangChain, MCP e LangFlow permitem que as equipes incorporem segurança diretamente em suas aplicações de IA – sem interromper os fluxos de trabalho de desenvolvimento.Experimente você mesmo aqui. o

Dito isto, este campo ainda é relativamente novo, e as melhores práticas para proteger os agentes de IA ainda estão evoluindo.O Quadro de Quatro Perímetros é uma abordagem experimental, e embora forneça uma base sólida, eu reconheço que as implementações do mundo real sempre exigem mais refinamento e adaptação.

Gostaria de ouvir o seu feedback, pensamentos e idéias sobre como melhorar este quadro para torná-lo ainda melhor para sistemas de IA prontos para produção - comentar aqui, ou me pegar em nossoSlack Comunidade. o