כאשר סוכן AI נושא עמו את ההרשאות שלו ומתקשר ישירות לשירותים חיצוניים, הוא פועל פחות כמו תוכנה של עובד ויותר כמו קבלן עם כרטיס אציל ללא מנהל. אינכם יכולים לראות למה הוא נגע, מי אישר את הגישה, או מדוע שיחה אחת עלתה פי עשרה משיחה אחרת. הלוגים מתפזרים על פני תריסר שירותים. השאלות מתרבות.
באיזה כלי הסוכן השתמש בפועל? מי העניק לו הרשאה לגעת במסד הנתונים הזה? מדוע ההרצה של יום שלישי שרפה ארבעים אלף טוקנים בעוד שביום שני נעשה שימוש בחמישה? כמה באמת הוצאנו?
ללא שכבת בקרה מרכזית הממוקמת בין המשתמשים, המודלים והשירותים, השאלות הללו נותרות ללא מענה. אתם זקוקים למשטח (plane) יחיד שרושם כל חיבור פעם אחת, חושף רק את קבוצת הפונקציות המצומצמת שהסוכן באמת צריך, ומתעד כל הרצה במלואה. מאמר זה מלווה מעבדה מתקדמת המשתמשת ב-deco Studio כמשטח הבקרה המקומי הזה. אתם תגדירו אותו, תחברו שרת Model Context Protocol בטוח, תחשפו בדיוק פונקציה אחת מורשית, ותצפו במה שקורה כאשר סוכן מנסה לחרוג מהגבולות שלו.
הבעיה עם הרשאות מפוזרות
דמיינו צוות טיפוסי. מפתח אחד מחבר סוכן ל-API חיפוש באמצעות מפתח אישי. מפתח אחר מחבר את אותו סוכן למסד נתונים של סביבת ייצור (production) כי הדמו נראה בלתי מזיק. שלישי מוסיף כלי לבדיקת חיובים כדי שהסוכן יוכל "לעזור עם חשבוניות". כל חיבור כזה אינו נראה לאחרים. לסוכן יש כעת גישה ישירה לחיפוש, לנתוני ייצור ולרשומות פיננסיות, אך לצוות אין רשימה מאוחדת של מה שפעיל.
כאשר ההרשאות נמצאות בתוך הסוכן, הממשל (governance) קורס. אינכם יכולים לבטל גישה באופן מרכזי מכיוון שהמפתח נמצא בזיכרון של הסוכן או בקובץ הסביבה המקומי שלו. אינכם יכולים לבצע ביקורת שימוש (audit) מכיוון שהשירות החיצוני רואה רק קריאת API מלקוח אוטומטי אנונימי. הפתעות בעלויות מופיעות ימים לאחר מכן בחשבון הענן, ועד אז אף אחד לא זוכר איזה prompt גרם לזינוק.
בניית משטח הבקרה שלכם ב-deco Studio
deco Studio פותר זאת על ידי פעולה כמרכז (hub) מקומי. אתם מריצים אותו במכונה שלכם, והוא הופך למקום היחיד שבו נמצאים ההגדרות. במקום לפזר מפתחות API והגדרות כלים בין סוכנים שונים, אתם רושמים חיבור פעם אחת בתוך Studio. לאחר מכן, אתם מחליטים בדיוק אילו פונקציות כל סוכן יכול לראות.
חשבו על זה כעל התקנת לוח תחנות (switchboard). כל החיווט עובר לחדר אחד. אתם בוחרים אילו קווים יתחברו לאילו מחלקות, ושומרים תיעוד של כל שיחה.
התחילו בהרצת deco Studio באופן מקומי. ברגע שהוא פועל, אתם מרכזים את ההגדרות. כל סוכן שרוצה להשתמש בכלי חייב כעת לפנות למשטח הבקרה, ולא לשירות החיצוני ישירות. זה יוצר מיד נקודת צרימה (chokepoint) שבה תוכלו לצפות, לסנן ולתעד (log).
חיבור שרת MCP בטוח
במעבדה זו, אתם מחברים שרת Model Context Protocol. MCP הוא תקן פתוח המאפשר למודלים לתקשר עם כלים חיצוניים, אך תקנים אינם מבטיחים בטיחות. השלב הקריטי כאן הוא הסלקטיביות. אינכם חושפים באופן עיוור כל endpoint שהשרת מציע. אתם רושמים את השרת ב-deco Studio, ואז חושפים רק פונקציה אחת מורשית לסוכן הבדיקה שלכם.
לדוגמה, שרת ה-MCP שלכם עשוי להציע עשר פונקציות: קריאת קובץ, כתיבת קובץ, שאילתת מסד נתונים, שליפת רשת ואחרות. אתם בוחרים פעולה אחת בלתי מזיקה, אולי מחשבון בתוך סביבה מבודדת (sandboxed calculator) או חיפוש לקריאה בלבד מול נתונים סינתטיים, וחושפים רק אותה. תשע הפונקציות האחרות הופכות לבלתי נראות עבור הסוכן. אם הסוכן יבקש אותן, משטח הבקרה יחזיר סירוב מוחלט.
זהו עיקרון "ההרשאה המינימלית" (least privilege) שהופך למכני. הסוכן מקבל יכולת לא באמצעות הוראה מנומסת, אלא באמצעות גבול תוכנה.
בדיקת הגבולות
צרו סוכן בדיקה וכוונו אותו למשטח הבקרה של deco Studio. תנו לו משימה הדורשת את הפונקציה המורשית היחידה. צפו בו מצליח. הלוגים בתוך Studio יציגו את בקשת המודל, את ניתוב קריאת הכלי דרך משטח הבקרה, את ביצוע הפונקציה ואת התוצאה שחוזרת למודל. תוכלו לקרוא את המסלול כולו ב-trace רציף אחד.
Now give the agent a second task that requires a function you deliberately excluded. The agent might attempt to reason its way around the limitation, or it might hallucinate that the tool exists. Either way, the call hits the control plane, the allowlist rejects it, and the execution fails. That failure is your proof that the boundary is software-enforced, not theoretical.
Do this with synthetic tasks first. Build a fake database full of generated user profiles. Let the agent query it. Verify the allowlist and the denials. Only after you trust the boundary should you even consider pointing the agent at production systems. Rushing to real data before you verify the wall is how secrets leak.
Reading the Full Path of a Run
deco Studio lets you inspect every layer of an execution. You see the raw model request: the prompt, the context window, the formatting. You see the tool call the model decided to make. You see the control plane route that call, the function execute, and the payload return. Finally, you see how the model consumes that result to form its answer.
This visibility answers the basic audit questions. You know which tool fired because the control plane logged it. You know who granted access because the configuration records sit in one local registry. You know why the run was expensive because you can count the tokens.
Counting What Matters
For every run, track four specific metrics. First, input and output tokens. These drive the bulk of model costs, and you need exact counts, not rough estimates. Second, separate model latency from tool latency. The time between your prompt and the model's response is different from the time the external service takes to answer a tool call. Confusing the two leads to misdiagnosed slowdowns. Third, calculate cost based on verified provider rates. Do not guess. Check your provider's pricing sheet and match it against the measured tokens. Fourth, compare successful calls against rejected unauthorized calls. A high rejection count means your agent is probing boundaries or your allowlist is misaligned with legitimate needs.
These numbers turn agent operations from a black-box subscription into an observable system. You can budget, optimize, and explain.
The Difference Between Local Control and Local Execution
Here is a lesson that trips up even careful builders. Running deco Studio on your machine gives you local control over configuration, but it does not guarantee local execution of the model itself. If you configure the agent to call an external provider such as OpenAI, Anthropic, or any hosted API, your prompts leave your machine. Studio manages the gate, but the data still crosses the network.
Always track these boundaries. Know which parts of the pipeline stay on localhost and which bits travel to someone else's server. If your data is sensitive, local control of the tool layer is not enough. You also need to know where the model inference happens. Do not confuse the comfort of a local dashboard with the reality of a remote model.
Instructions Are Not Authorization
One dangerous shortcut is trying to secure an agent through prompting. Telling the model, "Never call the delete function," is not a security control. It is a suggestion. Models can misinterpret instructions, jailbreak prompts, or simply make reasoning errors. Real security lives at the software boundary.
Use allowlists inside deco Studio to define exactly which functions are callable. Enforce those limits with server-side checks inside the control plane. The agent should discover its capabilities the way a user discovers file permissions: by hitting a hard limit, not by reading a friendly note. Security belongs in architecture, not in natural language.
Start Small, Stay Skeptical
Build your control plane one step at a time. One MCP server. One exposed function. One synthetic task. Verify that the agent succeeds where it should and fails where it must. Read the trace. Confirm the token counts. Then add the next tool.
Control is not a switch you flip. It is a habit of proving boundaries before you trust them. deco Studio gives you the local plane to practice that habit. Use it to turn a swarm of autonomous agents into a managed, observable, and bounded system.
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
קהילת למידה אופציונלית: GyaanSetu AI בטלגרם