How to give AI agents tool access safely

The moment an AI agent can use tools, it stops being a chat feature and becomes production infrastructure. It can read customer records, draft emails, open pull requests, query billing, post in Slack, or touch an internal API. At that point the hard question is not “can the model call the tool?” It is who gave it access, how narrow is that access, what happens before a risky action runs, and what audit trail remains afterward?

Neuro OS was built around that boundary. Tool access does not belong in a prompt and raw credentials do not belong in an agent sandbox. In Neuro OS, connections are part of the project operating layer: declared as files, brokered server-side, granted per agent, governed by policy, and reviewed when durable work changes the company. If you want the larger architecture first, read Introducing Neuro OS or the company OS post.

The rest of the market is converging on the same lesson. Auth0 calls out over-privileged tokens, prompt-injection exposure, and missing audit trails as common risks when teams hand API keys to agents. WorkOS argues agents need their own scoped, revocable credentials instead of borrowing a user’s full session. Promptfoo’s OWASP Agentic AI summary lists Tool Misuse and Identity and Privilege Abuse as core agentic risks. The pattern is clear: agent security is mostly tool security.

Чат безвреден, пока не затрагивает системы

A model drafting text in a window has a small blast radius. A model with connected tools has the blast radius of those tools. That is not a reason to keep agents powerless; powerless agents do not run companies. It is a reason to treat the connector layer as seriously as you treat IAM, secrets, and production deploys.

• A support agent may need to read tickets and invoices, but should not be able to refund money without approval.
• A finance agent may need to pull Stripe, bank, and warehouse data, but should not be able to send vendor payments from the same path.
• A recruiting agent may need to enrich candidates and draft outreach, but should not send messages without a human approving the final copy.
• An engineering agent may need GitHub, Linear, CI, and preview access, but should land work through a reviewed change request instead of mutating main directly.

The control plane cannot be “the prompt told the agent to be careful.” The control plane has to be outside the model.

The five rules of safe tool access

A production agent platform needs five layers before you can comfortably connect real company systems:

• Keep credentials out of the sandbox. The agent should never receive a third-party API key unless the task truly requires direct process-level access. Connector credentials should be resolved server-side and injected into the upstream request, not into model context.
• Grant tools per agent. Connecting Slack, Gmail, Stripe, or GitHub to a project is not the same as letting every agent call it. The support agent and release agent need different reach.
• Gate individual actions. Read operations, write operations, deletes, sends, payments, and admin changes should not share one permission bit. Tool names need policy: always run, require approval, or block.
• Make risky calls human-reviewable. A good agent can prepare the exact action and evidence. The platform should pause at the boundary where a human decision is required.
• Route durable change through review. If the agent edits the operating layer — agents, skills, triggers, memory, policies, or code — that work should be a diff someone can review, merge, and roll back.

How Neuro OS models a connector

Соединителем может быть приложение Pipedream, запускаемое одним щелчком мыши, удаленный сервер MCP, API OpenAPI или GraphQL, необработанный API HTTP, канал, например Slack, или подключенный компьютер. Это определение соответствует проекту; учетные данные живут на платформе. Агент видит каталог инструментов, а не кучу секретов.

разъемы:
  - слизняк: полоска
    провайдер: openapi
    спецификация: https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json
    политика:
      - совпадение: "*.get*"
        действие: Always_run
      - совпадение: "*.create*"
        действие: require_approval
      - совпадение: "*.delete*"
        действие: заблокировать

агенты:
  поддержка:
    разъемы: [обычные, полосатые]
    секреты: нет
    нейро_кли: нет

  релиз-бот:
    разъемы: [github, vercel]
    нейро_cli: [project.cr.open]

Этот пример намеренно скучен. Суть в том, что это скучно. Вы должны быть в состоянии ответить: «Куда может позвонить этот агент?» путем чтения файлов проекта, а не путем реверс-инжиниринга приглашения или проверки реального процесса.

Учетные данные на стороне сервера меняют режим сбоя

Когда учетные данные находятся в переменных среды внутри среды выполнения агента, каждая ошибка внедрения подсказки, ошибка ведения журнала, ошибка чтения файла и ошибка подпроцесса становятся возможной утечкой учетных данных. Когда учетные данные передаются на стороне сервера, агент может запросить вызов инструмента, но платформа решает, разрешен ли вызов, разрешает учетные данные, выполняет восходящий запрос и записывает, что произошло.

Это модель Neuro OS Connector. Каждый сеанс получает токен соединителя с ограниченной областью действия. Агент обнаруживает инструменты, описывает их схемы и вызывает их через API Neuro OS. Шлюз обеспечивает соблюдение политики предоставления грантов и соединителей проекта, разрешает учетные данные за пределами изолированной программной среды, выполняет запрос и проверяет вызов. Агент никогда не хранит учетные данные третьих лиц.

Токен инструмента с ограниченной областью действия не только безопаснее, чем необработанный ключ API. Это также делает журнал аудита осмысленным: идентификатор агента, имя инструмента, граница ввода, политическое решение, состояние утверждения и восходящий результат могут быть связаны вместе.

Опасный шаблон, который стоит удалить

Обычный ранний шаблон понятен: поместите STRIPE_SECRET_KEY, GITHUB_TOKEN, SLACK_BOT_TOKEN и дюжину других ключей в .env, запустите агент и надейтесь, что приглашение удержит его в пределах. Это работает для демо. Это неправильная форма для компании.

• Это слишком широко. Ключ обычно содержит все разрешения, которые имел владелец соединения, а не минимальное действие, необходимое агенту.
• Трудно определить причину. Нижестоящие системы видят общий ключ, а не агента, сеанс, человека или утверждение, вызвавшее звонок.
• Безопасно отозвать его сложно. Ротация общего ключа нарушает любой рабочий процесс с его использованием; если оставить его на месте, радиус взрыва будет большим.
• Он скрывает политику в коде и подсказках. Рецензентам безопасности нужны декларативные разрешения и журналы, а не «инструкции агента гласят, что ничего не удаляйте».

Быстрый аудит вашего стека агентов

Прежде чем подключать агентов к производственным системам, задайте следующие вопросы:

• Могу ли я перечислить все внешние системы, к которым может подключиться этот агент, не открывая приглашение агента?
• Могу ли я предоставить торговому агенту доступ на чтение CRM, не предоставляя ему при этом доступ на запись для выставления счетов?
• Могу ли я заблокировать удаление, потребовать одобрения отправки и разрешить безопасное чтение на одном и том же соединителе?
• Могу ли я увидеть, какой человек, агент, сеанс и политическое решение вызвали вызов инструмента?
• Могу ли я лишить доступа одного агента, не меняя общий ключ, который нарушает другие рабочие процессы?
• Может ли операционный уровень перейти из облака в VPC или локально без переписывания модели инструмента?

Если ответ отрицательный, возможно, у вас все еще есть полезный прототип агента. У вас еще нет защищенного командного центра ИИ.

Почему это проблема ОС компании

Безопасный доступ к инструментам не является отдельной функцией. Он работает только тогда, когда он находится рядом с остальным операционным уровнем компании: памятью, агентами, навыками, триггерами, секретами, политиками, песочницами и запросами на изменения. Грант на соединение указывает, к чему может прикасаться агент. Песочница ограничивает возможности ее запуска. Шлюз политики решает, какие вызовы требуют одобрения. Запрос на изменение записывает долговременные изменения как разницу. Репо сохраняет все в собственности и позволяет просматривать.

Вот почему Neuro OS позиционирует свой продукт как операционную систему автономной компании, а не как еще одного помощника с большим количеством разъемов. Компании не нужно еще одно место для вставки ключей. Ему необходим командный центр искусственного интеллекта на базе Git, где инструменты, учетные данные, политики и работа агентов являются частью одной и той же системы.

Подключите инструменты, держите ключи подальше от агента.

Начните с одного рабочего процесса, предоставляйте только те соединители, которые ему нужны, запрещайте рискованные действия и запускайте работу из репозитория, которым владеет ваша компания.

Узнать про Neuro OS →