დამტკიცების სამუშაო პროცესი

როდესაც ინსტრუმენტის უსაფრთხოების პოლიტიკა "supervised"-ზეა დაყენებული, PRX შესრულებას აპაუზებს და ადამიანის დამტკიცებას ელოდება ინსტრუმენტის გამოძახების გაშვებამდე. ეს კრიტიკულ უსაფრთხოების ფენას უზრუნველყოფს მაღალი რისკის ოპერაციებისთვის -- shell ბრძანებები, ფაილის ჩაწერა, ქსელის მოთხოვნები, ან ნებისმიერი მოქმედება, რომელსაც შეუქცევადი შედეგები შეიძლება ჰქონდეს.

მიმოხილვა

დამტკიცების სამუშაო პროცესი აგენტის ციკლსა და ინსტრუმენტის შესრულებას შორის მდებარეობს:

აგენტის ციკლი
    │
    ├── LLM გამოსცემს ინსტრუმენტის გამოძახებას: shell("rm -rf /tmp/data")
    │
    ▼
┌───────────────────────────────────┐
│        პოლიტიკის ძრავა           │
│                                   │
│  ინსტრუმენტი: "shell"            │
│  პოლიტიკა: "supervised"          │
│  მოქმედება: დამტკიცება სავალდებულო│
└───────────────┬───────────────────┘
                │
                ▼
┌───────────────────────────────────┐
│      დამტკიცების მოთხოვნა        │
│                                   │
│  მოლოდინში...                     │
│  ├── ზედამხედველის შეტყობინება   │
│  ├── პასუხის მოლოდინი            │
│  └── ვადაგასვლა N წამის შემდეგ   │
└───────────────┬───────────────────┘
                │
         ┌──────┴──────┐
         │             │
    ┌────▼────┐   ┌────▼────┐
    │დამტკიცდა│   │უარყოფილია│
    │         │   │         │
    │შესრულება│   │შეცდომის │
    │         │   │დაბრუნება│
    └─────────┘   └─────────┘

კონფიგურაცია

ინსტრუმენტთა პოლიტიკების დაყენება

განსაზღვრეთ რომელი ინსტრუმენტები მოითხოვს დამტკიცებას config.toml-ში:

[security.tool_policy]
# ნაგულისხმევი პოლიტიკა ყველა ინსტრუმენტისთვის.
# "allow" -- დაუყოვნებელი შესრულება
# "deny" -- შესრულების სრული დაბლოკვა
# "supervised" -- შესრულებამდე დამტკიცების მოთხოვნა
default = "allow"

# ინსტრუმენტის დონის პოლიტიკის გადაფარვები.
[security.tool_policy.tools]
shell = "supervised"
file_write = "supervised"
http_request = "supervised"
git_operations = "allow"
memory_store = "allow"
browser = "deny"

# ჯგუფის დონის პოლიტიკები.
[security.tool_policy.groups]
sessions = "allow"
automation = "supervised"

დამტკიცების პარამეტრები

[security.approval]
# რამდენ ხანს ელოდება პასუხს ვადაგასვლამდე (წამები).
timeout_secs = 300

# მოქმედება ვადაგასვლისას: "deny" ან "allow".
# "deny" უსაფრთხო ნაგულისხმევია -- უპასუხო მოთხოვნები უარყოფილია.
on_timeout = "deny"

# შეტყობინების არხი დამტკიცების მოთხოვნებისთვის.
# ზედამხედველი ამ არხის მეშვეობით ეცნობება.
notify_channel = "telegram"

# ზედამხედველის მომხმარებლის ID ან იდენტიფიკატორი.
# მხოლოდ ამ მომხმარებელს შეუძლია მოთხოვნების დამტკიცება ან უარყოფა.
supervisor_id = "admin"

# ავტო-დამტკიცების შაბლონები: ამ შაბლონებთან დამთხვეული
# ინსტრუმენტის გამოძახებები ავტომატურად მტკიცდება ადამიანის ჩარევის გარეშე.
# სიფრთხილით გამოიყენეთ.
[[security.approval.auto_approve]]
tool = "shell"
command_pattern = "^(ls|cat|head|tail|wc|grep|find|echo) "

[[security.approval.auto_approve]]
tool = "file_write"
path_pattern = "^/tmp/"

დამტკიცების ნაკადი

ნაბიჯი 1: პოლიტიკის შემოწმება

როდესაც აგენტი ინსტრუმენტის გამოძახებას გამოსცემს, პოლიტიკის ძრავა აფასებს მას:

1. ინსტრუმენტის დონის პოლიტიკის შემოწმება (security.tool_policy.tools.<name>)
2. თუ ინსტრუმენტის პოლიტიკა არ არსებობს, ჯგუფის პოლიტიკის შემოწმება (security.tool_policy.groups.<group>)
3. თუ ჯგუფის პოლიტიკა არ არსებობს, ნაგულისხმევი პოლიტიკის გამოყენება (security.tool_policy.default)

თუ გადაწყვეტილი პოლიტიკა "supervised"-ია, დამტკიცების ნაკადი აქტივირდება.

ნაბიჯი 2: ავტო-დამტკიცების შემოწმება

ზედამხედველის შეტყობინებამდე, PRX ამოწმებს ემთხვევა თუ არა მოთხოვნა რომელიმე auto_approve შაბლონს. ავტო-დამტკიცების წესები რეგულარული გამოსახულებების შაბლონებს იყენებს ინსტრუმენტის არგუმენტებთან შესადარებლად:

ველი	აღწერა
tool	ინსტრუმენტის სახელი, რომელზეც წესი ვრცელდება
command_pattern	რეგულარული გამოსახულების შაბლონი shell ბრძანებასთან შესადარებლად (shell ინსტრუმენტისთვის)
path_pattern	რეგულარული გამოსახულების შაბლონი ფაილის ბილიკებთან შესადარებლად (file_write, file_read)
url_pattern	რეგულარული გამოსახულების შაბლონი URL-ებთან შესადარებლად (http_request)
args_pattern	რეგულარული გამოსახულების შაბლონი სრულ JSON არგუმენტებთან შესადარებლად

თუ დამთხვევა აღმოჩნდა, მოთხოვნა ავტომატურად მტკიცდება და შესრულება დაუყოვნებლივ გრძელდება. ეს სასარგებლოა უსაფრთხო, მხოლოდ-წაკითხვის ბრძანებებისთვის, რომლებიც დამტკიცების გადაჭარბებულ დაღლილობას შექმნიდა.

ნაბიჯი 3: შეტყობინება

თუ ავტო-დამტკიცების წესი არ ემთხვევა, PRX დამტკიცების მოთხოვნას ქმნის და ზედამხედველს აცნობებს:

[დამტკიცება სავალდებულო]

ინსტრუმენტი: shell
არგუმენტები: {"command": "rm -rf /tmp/data"}
სესია: abc-123
აგენტი: default
დრო: 2026-03-21 14:30:22 UTC

უპასუხეთ:
  /approve -- ინსტრუმენტის გამოძახების შესრულება
  /deny -- ინსტრუმენტის გამოძახების უარყოფა
  /deny reason: <ახსნა> -- უარყოფა მიზეზით

შეტყობინება კონფიგურირებული notify_channel-ის მეშვეობით იგზავნება. მხარდაჭერილი არხები:

არხი	შეტყობინების მეთოდი
Telegram	შეტყობინება ზედამხედველის ჩატში
Discord	პირადი შეტყობინება ზედამხედველს
Slack	პირადი შეტყობინება ზედამხედველს
CLI	ტერმინალის მოთხოვნა (stdin)
Email	ელფოსტა კონფიგურირებულ მისამართზე
Webhook	HTTP POST კონფიგურირებულ URL-ზე

ნაბიჯი 4: მოლოდინი

აგენტის ციკლი პაუზირდება ზედამხედველის პასუხის მოლოდინში. ამ დროს:

• აგენტს არცერთი ინსტრუმენტის შესრულება არ შეუძლია (მიმდინარე ინსტრუმენტის გამოძახება ბლოკავს)
• სხვა სესიები დამოუკიდებლად განაგრძობს მუშაობას
• დამტკიცების მოთხოვნას უნიკალური ID აქვს თვალთვალისთვის

ნაბიჯი 5: გადაწყვეტა

ზედამხედველი ერთ-ერთით პასუხობს:

პასუხი	ეფექტი
დამტკიცება	ინსტრუმენტის გამოძახება ჩვეულებრივ სრულდება და შედეგი აგენტს უბრუნდება
უარყოფა	ინსტრუმენტის გამოძახება უარყოფილია და შეცდომის შეტყობინება აგენტს უბრუნდება
უარყოფა მიზეზით	იგივეა რაც უარყოფა, მაგრამ მიზეზი შეცდომის შეტყობინებაში შედის, რათა აგენტმა ადაპტირება შეძლოს
ვადაგასვლა	on_timeout მოქმედება გამოიყენება (ნაგულისხმევი: უარყოფა)

მოთხოვნის სიცოცხლის ციკლი

თითოეული დამტკიცების მოთხოვნა ამ მდგომარეობებში გადადის:

PENDING → APPROVED → EXECUTED
       → DENIED
       → TIMED_OUT
       → CANCELLED (თუ სესია გადაწყვეტამდე დასრულდა)

მდგომარეობა	აღწერა
PENDING	ზედამხედველის პასუხის მოლოდინში
APPROVED	ზედამხედველმა დაამტკიცა, ინსტრუმენტი სრულდება
EXECUTED	ინსტრუმენტის შესრულება დასრულდა დამტკიცების შემდეგ
DENIED	ზედამხედველმა ცალსახად უარყო მოთხოვნა
TIMED_OUT	პასუხი არ მიღებულა timeout_secs-ის ფარგლებში
CANCELLED	სესია გადაწყვეტამდე შეწყდა

დამტკიცების ინტერფეისები

CLI რეჟიმში დამტკიცების მოთხოვნები ინტერაქტიული ტერმინალის მოთხოვნების სახით ჩნდება ინსტრუმენტის სახელით, არგუმენტებითა და რისკის დონით. პროგრამული წვდომისთვის PRX REST API-ს გამოაქვეყნებს:

# მოლოდინში მყოფი მოთხოვნების ჩამონათვალი / დამტკიცება / უარყოფა
curl http://localhost:8080/api/approvals?status=pending
curl -X POST http://localhost:8080/api/approvals/{id}/approve
curl -X POST http://localhost:8080/api/approvals/{id}/deny \
  -d '{"reason": "Not permitted"}'

აუდიტის კვალი

ყველა დამტკიცების გადაწყვეტილება აქტივობის ჟურნალში აღირიცხება შემდეგი ველებით: request_id, tool, arguments, session_id, decision, decided_by, decided_at, reason და execution_result. წვდომა prx audit approvals --last 50-ით ან ექსპორტი --format json-ით.

უსაფრთხოების შენიშვნები

• ნაგულისხმევი უარყოფა ვადაგასვლისას -- საწარმოო გარემოში ყოველთვის დააყენეთ on_timeout = "deny". უპასუხო მოთხოვნების გაგრძელების ნებართვა ზედამხედველობის მიზანს ეწინააღმდეგება.
• ავტო-დამტკიცების სიფრთხილე -- ზედმეტად ფართო ავტო-დამტკიცების შაბლონებმა შეიძლება დამტკიცების სამუშაო პროცესი გვერდის ავლით დატოვოს. გამოიყენეთ კონკრეტული რეგულარული გამოსახულებები და რეგულარულად გადახედეთ მათ.
• ზედამხედველის ავთენტიფიკაცია -- დარწმუნდით, რომ notify_channel ზედამხედველს ავთენტიფიცირებს. კომპრომეტირებულმა შეტყობინების არხმა შეიძლება არაავტორიზებული დამტკიცებები დაუშვას.
• სიჩქარის შეზღუდვა -- თუ აგენტი ერთი და იმავე ოპერაციისთვის განმეორებით იწვევს დამტკიცების მოთხოვნებს, განიხილეთ ამ ინსტრუმენტის პოლიტიკის "deny"-ზე განახლება ან უფრო კონკრეტული ავტო-დამტკიცების წესის დამატება.
• მრავალ-ზედამხედველი -- გუნდურ განთავსებებში განიხილეთ მრავალი ზედამხედველის კონფიგურაცია. ნებისმიერ მათგანს შეუძლია დამტკიცება ან უარყოფა.

დაკავშირებული გვერდები

• უსაფრთხოების მიმოხილვა
• პოლიტიკის ძრავა
• სენდბოქსი
• აუდიტის ჟურნალი
• ინსტრუმენტების მიმოხილვა