შემიძლია AI აგენტს მხოლოდ წაკითხვის წვდომა მივცე?

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

როგორ შევზღუდო, რამდენს ხარჯავს აგენტი?

წინასწარი ბალანსით. ფულს მხოლოდ სამი ინსტრუმენტი ხარჯავს (order_vps, change_plan, create_sandbox) და სამივე ბალანსიდან ჭრის; თუ ბალანსი არ ყოფნის, ბრუნდება 402 ან გადაუხდელი ინვოისი. აგენტს შეუძლია შეავსების ან გადახდის ბმულის შექმნა, მაგრამ გადახდას კრიპტოსაფულე სჭირდება, ამიტომ იხდის ადამიანი. შენახული ბარათი არ არის და ბალანსი მინუსში ვერ გადავა.

რა უშლის ხელს აგენტს, წაშალოს ჩემი სერვერი?

reinstall_vps, reset_password და დაუყოვნებლივი cancel_service მოითხოვს, რომ confirm ზუსტად ჰოსტის სახელი იყოს (ხელახალი ინსტალაციისა და აღდგენისთვის DELETE-იც გამოდგება). ნაგულისხმევი გაუქმება end_of_period-ია: სერვერი აგრძელებს მუშაობას და undo_cancel მას აბრუნებს. დელეგირებულ ანგარიშებს გაუქმება საერთოდ არ შეუძლიათ. ველი confirm აჩერებს აგენტს, რომელიც ბუნდოვანი მითითებით მოქმედებს, და არა თავდამსხმელს თქვენი ტოკენით, ამიტომ MCP კლიენტშიც დააყენეთ ეს ინსტრუმენტები ყოველთვის კითხვაზე.

რა ვქნა, თუ ჩემი Bearer ტოკენი გაჟონა?

დაუყოვნებლივ გააუქმეთ (პანელი → პარამეტრები → API ტოკენები აგენტებისთვის, ან DELETE /auth/tokens/{id}). შემდეგ ტოკენების სიაში მოძებნეთ უცნობი ტოკენები, ნახეთ თითოეული სერვერის სერვისის ისტორია, ინვოისები და list_delegations, და შეცვალეთ root პაროლები იმ სერვერებზე, რომლებსაც ტოკენი ხედავდა: get_vps_status reveal-ით root პაროლს აბრუნებს.

რამდენი ინსტრუმენტი აქვს EQVPS-ის MCP სერვერს?

MCP სერვერის 1.6.0 ვერსიით (შემოწმდა 2026-10-04) კლიენტის ტოკენისთვის 45: 5 საჯარო, 15 მხოლოდ წასაკითხი, 17, რომლებიც მდგომარეობას ცვლის ხარჯის გარეშე, და 8, რომლებიც ფულს ხარჯავს, მონაცემებს შლის ან წვდომას აძლევს. რესელერის ტოკენები მათ ნაცვლად ხედავს 30 რესელერის ინსტრუმენტის ცალკე ნაკრებს, ერთსა და იმავე endpoint-ზე სულ 75.

MCP სერვერის უსაფრთხოება AI აგენტებისთვის

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

ბოლო შემოწმება: 2026-10-04 · MCP სერვერი 1.6.0 · 45 ინსტრუმენტი (კლიენტის ტოკენი)

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

ქვემოთ ყველაფერი შემოწმებულია მოქმედ სერვერზე გვერდის თავში მითითებულ თარიღში: ინსტრუმენტების სია აღებულია tools/list-დან მისამართზე https://mcp.eqvps.com/mcp, ზღვრები კი თავად API-დან. თუ ახალი ხართ, ჯერ წაიკითხეთ MCP კლიენტის დაკავშირება და API ტოკენები, შემდეგ დაბრუნდით.

საფრთხეების მოდელი: რა ფუჭდება სინამდვილეში

სამი რამ, იმ თანმიმდევრობით, რომლითაც ვხვდებით:

აგენტი არასწორად იგებს. „სატესტო მანქანა გაასუფთავე" იქცევა სხვა სერვერის ხელახალ ინსტალაციად. ბოროტი განზრახვა არ არის, მოდელმა უბრალოდ მითითების ხარვეზი თავად შეავსო.
Prompt injection. აგენტი კითხულობს ტექსტს, რომელიც თქვენ არ დაგიწერიათ (README, მხარდაჭერის პასუხი, ინტერნეტიდან ამოღებული გვერდი), და ეს ტექსტი რაღაცის გაკეთებას ეუბნება. თუ აგენტს სრული უფლებების ტოკენი აქვს, ჩადებულ მითითებასაც იგივე უფლებები აქვს.
ტოკენი ჟონავს. ის ხვდება shell-ის ისტორიაში, საჯარო რეპოზიტორიაში, საერთო MCP კონფიგურაციაში ან ლოგის რომელიმე ხაზში.

MCP სერვერი ამოწმებს, რომ ტოკენი ვალიდურია და სერვერი ამ ანგარიშს ეკუთვნის (ან მასზეა დელეგირებული). მან არ იცის, რას გულისხმობდით. ქვემოთ თითოეული დამცავი ზღვარი ერთ კითხვას პასუხობს: რამდენი ზიანია შესაძლებელი, თუ მითითება არასწორია?

MCP-ის ყველა ინსტრუმენტი რისკის დონეების მიხედვით

კლიენტის ტოკენი ხედავს 45 ინსტრუმენტს (MCP სერვერი 1.6.0). რესელერის ტოკენი (rk_…) ხედავს 30 რესელერის ინსტრუმენტის ცალკე ნაკრებს და არცერთს ამათგან, ამიტომ endpoint-ზე სულ 75 ინსტრუმენტია. თქვენი კლიენტი tools/list-დან მხოლოდ საკუთარ ნაკრებს იღებს.

ეს გვერდი ინსტრუმენტებს რისკის მიხედვით ალაგებს. თითოეულის პარამეტრები და გამოძახების მაგალითები არის პარამეტრების ცნობარში; ყველა ინსტრუმენტი ერთ ხაზზე, რესელერის 30 ინსტრუმენტის ჩათვლით, არის სრულ სიაში.

MCP ინსტრუმენტების ანოტაციებს (readOnlyHint, destructiveHint) ჯერ არ ვაგზავნით, ამიტომ კლიენტი მათ თავად ვერ დაალაგებს. დადასტურებები ხელით დააყენეთ ქვემოთ მოცემული დონეების მიხედვით.

დონე 0 — საჯარო, ტოკენის გარეშე (5)

ინსტრუმენტი	რას აკეთებს
`get_started`	მთელი პროცესი ერთ პასუხში: რომელი ინსტრუმენტები, რა თანმიმდევრობით
`list_plans`	გეგმები, ფასები, ოპერაციული სისტემების იმიჯები
`sandbox_pricing`	sandbox-ის ფასები
`register_account`	ქმნის ახალ ანგარიშს და აბრუნებს მის ტოკენს
`login`	ელფოსტა + პაროლი → ტოკენი

დონე 1 — ანგარიშის წაკითხვა, გვერდითი ეფექტების გარეშე (15)

ინსტრუმენტი	რას აკეთებს	ყურადღება
`whoami`	ანგარიშის id, სახელი, ელფოსტა
`get_balance`	წინასწარი ბალანსი
`list_vps`	აქტიური, შექმნის პროცესში მყოფი და შეჩერებული სერვერები
`get_vps_status`	მდგომარეობა, მახასიათებლები, წვდომის მონაცემები	`reveal: true`-ით აბრუნებს root პაროლს
`get_vps_metrics`	CPU, მეხსიერება, ქსელი, დისკი დროის მიხედვით
`get_upgrade_options`	გეგმები, რომლებზეც სერვერი ხელახალი ინსტალაციის გარეშე გადადის
`list_delegations`	ვის მიეცით წვდომა
`list_delegated_to_me`	სერვერები, რომლებიც სხვებმა დაგიდელეგირეს
`list_tickets`	თქვენი მხარდაჭერის ბილეთები
`get_ticket`	ერთი ბილეთი მთელი მიმოწერით	ბილეთის ტექსტი აგენტისთვის არასანდო შეყვანაა
`list_sandboxes`	თქვენი sandbox-ები
`get_sandbox`	ერთი sandbox და მისი მოხმარება
`get_task`	ფონური ამოცანის გამონატანი
`download_file`	კითხულობს პატარა ფაილს sandbox-იდან
`get_download_url`	მოკლევადიანი ბმული sandbox-ის ერთ ფაილზე	ბმულის მქონე ნებისმიერს შეუძლია ჩამოტვირთვა, სანამ ვადა არ ამოიწურება

დონე 2 — ცვლის მდგომარეობას, არაფერს ხარჯავს (17)

ინსტრუმენტი	რას აკეთებს	ყურადღება
`power_vps`	start / stop / reboot	stop ნამდვილად stop-ია: სერვისები ჩერდება
`set_hostname`	ცვლის სერვერის სახელს	ცვლის სწორედ იმ მნიშვნელობას, რომელსაც `confirm` ადარებს
`undo_cancel`	აუქმებს პერიოდის ბოლოს დაგეგმილ გაუქმებას
`refresh_token`	ახალი ტოკენი, ძველი მაშინვე უქმდება	შემდეგ განაახლეთ სტატიკური კონფიგურაცია
`set_password`	აყენებს ანგარიშის პაროლს, თუ ჯერ არ არის	ტოკენის მფლობელმა შეიძლება თქვენზე ადრე დააყენოს
`topup_balance`	შევსების ინვოისი + კრიპტოგადახდის ბმული	გადახდას საფულე სჭირდება
`pay_invoice`	გადაუხდელი ინვოისის გადახდის ბმული	იგივე
`accept_delegation`	იღებს მოწვევას
`revoke_delegation`	ასრულებს დელეგირებას
`create_ticket` / `reply_ticket` / `close_ticket`	მხარდაჭერის ბილეთები	აგენტი თქვენი სახელით წერს მხარდაჭერას
`run_code` / `exec_command`	უშვებს კოდს sandbox-ში	მხოლოდ sandbox-ში, არა თქვენს VPS-ზე
`kill_task`	აჩერებს sandbox-ის ფონურ ამოცანას
`upload_file` / `get_upload_url`	დებს ფაილს sandbox-ში

დონე 3 — ხარჯავს ფულს, შლის მონაცემებს ან აძლევს წვდომას (8)

ინსტრუმენტი	რას აკეთებს	შემოწმება სერვერის მხარეს
`order_vps`	უკვეთავს სერვერს, ბალანსიდან გადახდით	ბალანსი არ ყოფნის → გადაუხდელი ინვოისი, არაფერი ჩამოიჭრება
`change_plan`	გეგმის შეცვლა ხელახალი ინსტალაციის გარეშე, სხვაობა ბალანსიდან	`confirm: true`; ბალანსი არ ყოფნის → 402
`create_sandbox`	უშვებს ფასიან sandbox-ს	ცარიელი ბალანსი → 402
`reinstall_vps`	შლის დისკს და აყენებს ახალ ოპერაციულ სისტემას	`confirm` = ზუსტი ჰოსტის სახელი ან `DELETE`; 4 გამოძახება/წთ
`reset_password`	ახალი root პაროლი, ძველი აღარ მუშაობს	`confirm` = ჰოსტის სახელი ან `DELETE`; 6 გამოძახება/წთ
`cancel_service`	`end_of_period` (ნაგულისხმევი, შექცევადი) ან `immediate` (სერვერს მაშინვე ანადგურებს)	`immediate`-ს სჭირდება `confirm` = ჰოსტის სახელი
`kill_sandbox`	შლის sandbox-ს ფაილებიანად	არა
`delegate_service`	სხვა ადამიანს აძლევს ოპერატორის წვდომას სერვერზე	მხოლოდ მფლობელი; მეორე მხარემ უნდა დაეთანხმოს

ინსტრუმენტების ნაკრების ცვლილებების ჟურნალი

თარიღი	სერვერის ვერსია	ცვლილება	გავლენა რისკზე
2026-10-03	1.6.0	დაემატა `refresh_token`; ტოკენები ნაგულისხმევად 1 წელი მოქმედებს	დონე 2
2026-10-03	1.5.0	`undo_cancel`, `get_upgrade_options`, `change_plan`	`change_plan` ხარჯავს ბალანსს → დონე 3
2026-10-03	1.1.0	13 sandbox-ის ინსტრუმენტი	`create_sandbox` ხარჯავს, `kill_sandbox` შლის → დონე 3

მოქმედი ვერსია საჯაროა: curl -s https://mcp.eqvps.com/healthz. როცა შეიცვლება, ეს ცხრილიც შეიცვლება.

ბალანსი ხარჯის ზღვარია

EQVPS წინასწარი გადახდით მუშაობს. შენახული ბარათი, საკრედიტო ხაზი და მინუსი არ არსებობს: მაქსიმუმი, რისი დახარჯვაც აგენტს შეუძლია, ის არის, რაც ბალანსზე დევს. ფულს სამი ინსტრუმენტი ხარჯავს: order_vps, change_plan და create_sandbox. თქვენი არსებული სერვერების განახლებაც იმავე ბალანსიდან ჩამოიჭრება.

აგენტს შეუძლია ფულის მოთხოვნის შექმნა, მაგრამ არა გადახდა. topup_balance და pay_invoice აბრუნებს კრიპტოგადახდის ბმულს, ხოლო ბმული საფულის გარეშე არაფერს აკეთებს. თანხის გატანის endpoint-იც არ არსებობს: ბალანსზე არსებული ფული თქვენს ანგარიშში სერვისების ყიდვას შეუძლია, გარეთ გატანა კი არა. დაუყოვნებლივი გაუქმების დაბრუნებული თანხაც ბალანსზე ბრუნდება.

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

მინიმალური უფლებები: მხოლოდ წაკითხვის ტოკენი (ჯერ) არ არსებობს

პირდაპირ: ყველა კლიენტის ტოკენს იგივე უფლებები აქვს, რაც ანგარიშს პანელში. ტოკენის სახელი და ვადა რეგულირდება, უფლებების არეალი (scopes) — არა.

დღეს ყველაზე ვიწრო ვარიანტი დელეგირებაა. აგენტს აძლევთ საკუთარ ანგარიშს ნულოვანი ბალანსით და უდელეგირებთ ერთ სერვერს:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

იგივე REST-ით:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

მოწვევა უნდა მიიღოთ ამ ელფოსტით შესულ მდგომარეობაში (accept_delegation), ხოლო expires_days შეიძლება იყოს 1-დან 365-მდე. ნაბიჯ-ნაბიჯ ეკრანის ანაბეჭდებით: წვდომის დელეგირება და წვდომა დოკუმენტაციაში.

დელეგირებულ ანგარიშს შეუძლია	დელეგირებულ ანგარიშს არ შეუძლია
ნახოს ამ ერთი სერვერის მდგომარეობა, მეტრიკები და ისტორია	ნახოს თქვენი სხვა სერვერები, ბალანსი ან ინვოისები
ჩართოს, გამორთოს, გადატვირთოს	გააუქმოს, განაახლოს ან შეცვალოს გეგმა
დააყენოს ჰოსტის სახელი და უკუ-DNS	იყიდოს დამატებები ან IP მისამართები
აღადგინოს root პაროლი	გახსნას ვებ-კონსოლი
ხელახლა დააინსტალიროს ოპერაციული სისტემა	სერვერი სხვას დაუდელეგიროს

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

ტოკენის ჰიგიენა

თითო აგენტს თითო ტოკენი, სახელით. შექმენით პანელი → პარამეტრები → API ტოკენები აგენტებისთვის განყოფილებაში, ან ასე:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

ტოკენი მხოლოდ ერთხელ ჩანს. ვადა 1-დან 1825 დღემდე, თუ არ მიუთითებთ — 365. აგენტებისთვის ჩვენ 90-ს ავირჩევდით.

შეინახეთ ფაილში, რომლის წაკითხვაც მხოლოდ თქვენ შეგიძლიათ, არა რეპოზიტორიაში, არა პრომპტში და არა shell-ის ცვლადში, რომელსაც აქეთ-იქით აკოპირებთ:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # მოსალოდნელია: -rw-------

შემდეგ ჩატვირთეთ აგენტის სერვისში EnvironmentFile=-ით (systemd) ან set -a; . ~/.config/eqvps/agent.env; set +a-ით.

შეცვალეთ ვადის ამოწურვამდე. ინსტრუმენტი refresh_token ან POST /auth/tokens/{id}/refresh გასცემს ახალ ტოკენს იმავე სახელით და ძველს მაშინვე აუქმებს. თუ ტოკენი MCP კლიენტის კონფიგურაციაშია ჩაწერილი, მაშინვე განაახლეთ, თორემ შემდეგი სესია 401-ს მიიღებს.

შეამოწმეთ, ვინ რას იყენებს: GET /auth/tokens აჩვენებს თითოეულ ტოკენს სახელით, ვადით და last_used_at-ით. უცნობი ტოკენი, ან ტოკენი, რომელიც აგენტის გამორთვის შემდეგ იქნა გამოყენებული, თქვენთვის განგაშის სიგნალია.

თუ ტოკენი გაჟონა

ამ თანმიმდევრობით:

გააუქმეთ. პანელი → პარამეტრები → API ტოკენები აგენტებისთვის → გაუქმება, ან curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. მომდევნო მოთხოვნიდან აღარ მუშაობს.
მოძებნეთ ახალი ტოკენები, რომლებიც თქვენ არ შეგიქმნიათ, და ისინიც გააუქმეთ.
შეამოწმეთ, რა შეიძლება დაზარალდა: თითოეული სერვერის სერვისის ისტორია, ინვოისები და ბალანსი, და list_delegations — ხომ არ არის წვდომა, რომელიც თქვენ არ მიგიციათ.
შეცვალეთ root პაროლები ყველა სერვერზე, რომელსაც ეს ტოკენი ხედავდა. get_vps_status reveal: true-ით გასცემს root პაროლს, ამიტომ გაჟონილი ტოკენი გაჟონილი root პაროლია. ამავდროულად შეამოწმეთ ~/.ssh/authorized_keys.
დახურეთ პაროლის კარი. თუ თქვენს ანგარიშს პაროლი არასდროს ჰქონია, ტოკენის მფლობელს შეეძლო set_password-ით დაეყენებინა. შედით ელფოსტის კოდით და შეცვალეთ პაროლი.

მე-5 ნაბიჯის პრევენცია უფასოა: ახლავე თავად დააყენეთ ანგარიშის პაროლი და set_password ყველას, ვინც თქვენ შემდეგ მოვა, 409-ს დაუბრუნებს.

ადამიანის დადასტურება

რას აწესებს სერვერი:

reinstall_vps, reset_password და cancel_service type: immediate-ით მოითხოვს, რომ confirm ზუსტი ჰოსტის სახელი იყოს (DELETE ხელახალი ინსტალაციისა და აღდგენისთვისაც მუშაობს).
change_plan მოითხოვს confirm: true-ს.
ნაგულისხმევი გაუქმება end_of_period-ია: სერვერი გადახდილი პერიოდის ბოლომდე მუშაობს, undo_cancel კი მას აბრუნებს.
სიჩქარის ზღვრები ანგარიშზე: ხელახალი ინსტალაცია 4/წთ, პაროლის აღდგენა 6/წთ, კვება 20/წთ, შეკვეთები 20/წთ. საკმარისია, რომ ციკლში გაჭედილმა აგენტმა ერთი და იგივე ორმოცდაათჯერ არ გააკეთოს, მაგრამ არა ერთი არასწორი გამოძახების შესაჩერებლად.

მკაფიოდ გაიაზრეთ, რა არის confirm. ის აგენტს უშლის ხელს, იმოქმედოს „იქ გაასუფთავე"-ს საფუძველზე. თავდამსხმელს ვერ აჩერებს, რადგან ჰოსტის სახელი ერთი get_vps_status გამოძახების მანძილზეა. ნამდვილი დადასტურება თქვენს MCP კლიენტშია. კლიენტების უმეტესობას შეუძლია ყოველი ინსტრუმენტის გამოძახებამდე იკითხოს: დონეები 0 და 1 თავისუფლად გაუშვით, დონე 3 კი ყოველთვის კითხვაზე დააყენეთ. კლიენტებში, სადაც უფლებები თითოეულ ინსტრუმენტზე ცალკე ყენდება, მაგალითად Claude Code-ის settings.json-ში (სერვერი დარეგისტრირებულია eqvps სახელით):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

დაამატეთ ერთი ხაზი აგენტის ინსტრუქციებშიც. თავისთავად ეს უსაფრთხოების საშუალება არ არის, მაგრამ „ვერ გაიგო" შემთხვევებს ამცირებს (დატოვეთ ინგლისურად, მოდელები მას ერთნაირად იგებენ):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

თუ აგენტი გრძელვადიანი ტოკენის ნაცვლად ელფოსტის კოდით შედის, იხილეთ აგენტის შესვლა MCP-ით.

აუდიტი: რას ხედავთ შემდეგ

ტოკენების სია (GET /auth/tokens, ან პარამეტრები → API ტოკენები აგენტებისთვის): სახელი, შექმნის თარიღი, ვადა, last_used_at. სწორედ ამიტომ ღირს ტოკენების აგენტების მიხედვით დასახელება.
სერვისის ისტორია (პანელი, სერვერის გვერდი): კვების ოპერაციები, ხელახალი ინსტალაციები, პაროლის აღდგენები, გეგმის ცვლილებები, გადახდები, თითოეული დროით და შემსრულებლით: თქვენ, მხარდაჭერა ან ავტომატურად. ის არ გეუბნებათ, რომელმა ტოკენმა ან რომელმა დელეგატმა იმოქმედა, მხოლოდ იმას, რომ მოქმედება თქვენი მხრიდან მოვიდა.
ინვოისები და ბალანსი: ყოველი ჩამოჭრა და დაბრუნება.
list_delegations: ვის რაზე აქვს წვდომა და როდემდე.

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

კონფიგურაცია, რომელსაც ჩვენ ავირჩევდით

აგენტისთვის, რომელიც ერთ საწარმოო სერვერს მართავს:

ცალკე ანგარიში აგენტისთვის, ნულოვანი ბალანსი, სერვერი დელეგირებულია expires_days: 90-ით.
მფლობელის ტოკენი თქვენთან რჩება და არცერთ აგენტის კონფიგურაციაში არ დევს.
სარეზერვო ასლები ამ სერვერზე, რადგან დელეგატს ხელახალი ინსტალაცია შეუძლია.
დონე 3-ის ინსტრუმენტები კლიენტში „ask"-ზე ან „deny"-ზე.
აგენტის ტოკენი 600 უფლებების ფაილში, ვადის ამოწურვამდე განახლებული.

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

MCP-ის დამცავი ზღვრები: უსაფრთხო უფლებები AI აგენტებისთვის