Observability, bezpieczeństwo i kontrola
- data
- kategoria
- AI Agents
- także w
- Observability · Application Security
- czytanie
- 2 min / 489 słów
To jeden z największych kroków względem pojedynczego agenta.
Jeżeli agent działa w jednym zespole, można jeszcze zajrzeć do jego logów i ręcznie sprawdzić, co zrobił.
Przy dziesiątkach agentów organizacja musi mieć normalną warstwę observability.
Nie tylko:
HTTP 200
CPU 30%
ale również:
jaki task dostał?
którego modelu użył?
jakiego RAG użył?
jakie dokumenty dostał?
które tools wywołał?
z jakimi argumentami?
co tool zwrócił?
ile tokenów zużył?
ile trwał task?
co wysłał na zewnątrz?
co znalazło się w finalnym output?
Trace jednego taska
Dla PAY-123 możemy zobaczyć:
PAY-123
|
v
jira.get_issue
|
v
git clone
|
v
model call
|
v
engineering_docs.search
|
v
model call
|
v
edit files
|
v
run tests
|
v
github.create_pull_request
Każdy krok może być spanem w trace.
To zaczyna przypominać distributed tracing znany z microservices.
Co mierzymy operacyjnie
Runtime
- request count,
- latency,
- failures,
- retries,
- CPU/memory.
Model
- model calls,
- token usage,
- latency,
- koszt.
Tools
- który tool został użyty,
- ile razy,
- z jakim wynikiem,
- gdzie występują błędy.
Workflow
- czas wykonania taska,
- liczba kroków,
- ile razy agent wracał do modelu,
- gdzie najczęściej się zatrzymuje.
Analiza inputów i outputów
Przy agentach ważne jest również to, co przepływa przez system.
Możemy analizować:
- prompt injection,
- próby wyciągnięcia system promptu,
- sekrety w promptach,
- klucze API w tool arguments,
- dane osobowe,
- dane poufne w outputach,
- nieautoryzowane informacje wracające z RAG.
Przykład:
tool output
contains AWS_SECRET_KEY
|
v
security control
|
v
block / redact / alert
Albo:
retrieved document
contains malicious instruction:
"ignore previous instructions..."
|
v
prompt injection detection
|
v
block / flag
Guardrails i policies
Nie wszystko powinno zależeć od decyzji modelu.
Możemy mieć deterministyczną policy:
Implementer Agent
MAY:
- read repo
- create branch
- create PR
MUST NOT:
- merge PR
- delete repo
- deploy production
Tool gateway może odrzucić niedozwolone działanie nawet wtedy, gdy model spróbuje je wykonać.
Gdzie konfigurujemy observability
Repo agenta
Dodaje telemetry context:
agent = implementer
issue = PAY-123
repo = payments-service
team = payments
i ewentualne custom spans.
Platforma
Zapewnia:
- trace backend,
- logi,
- dashboardy,
- alerty,
- retencję,
- dostęp do telemetry,
- security filters,
- redaction.
Tool gateway / guardrails
Kontroluje input/output na granicy tool calls.
Narzędzia na rynku
| Obszar | Azure | AWS | GCP | Niezależne |
|---|---|---|---|---|
| Agent tracing | Foundry Tracing + Application Insights | AgentCore Observability + CloudWatch | Cloud Trace + Agent Engine telemetry | OpenTelemetry, Langfuse, LangSmith |
| Runtime metrics | Azure Monitor / App Insights | CloudWatch | Cloud Monitoring | Grafana / OTEL backend |
| Prompt / output safety | Foundry Guardrails, Prompt Shields | Bedrock Guardrails / AgentCore Policy | Vertex AI safety controls (Model Armor) | własne filters |
| Sensitive data | redaction + protected trace data / Azure security stack | sensitive information guardrails | Google Cloud DLP / security controls | custom DLP |
| Tool policy | Foundry identity/policies around tools | AgentCore Policy + Gateway | IAM / Agent Gateway policies | własny policy layer |
Ważny detal: traces też są danymi
Trace może zawierać:
- user input,
- model output,
- tool arguments,
- tool results.
Czyli observability samo może stać się źródłem wycieku.
Dlatego organizacja musi kontrolować:
- czy zapisujemy pełną treść promptów,
- co redagujemy,
- kto ma dostęp do trace,
- jak długo je trzymamy.
Observability nie jest dodatkiem na koniec.
Przy agentach staje się częścią mechanizmu kontroli.