שימוש בזהות הסוכן עם Agent Runtime

שימוש ב-Agent Identity ב-Agent Runtime מספק זהות מאובטחת לכל סוכן, שמאפשרת גישה עם הרשאות מינימליות לניהול הרשאות גישה. במאמר הזה מוסבר איך ליצור נציגים עם זהויות, לאשר גישה לממשקי API שלGoogle Cloud ולנהל את פרטי הכניסה לשירותים של צד שלישי.

סקירה כללית

לכל סוכן יש זהות משלו, שמאפשרת גישה לפי העיקרון של הרשאות מינימליות וקשורה למחזור החיים של הסוכן. לכן, זהות הסוכן היא חשבון משתמש מאובטח יותר מחשבונות שירות. אמצעי הבקרה הקיימים לניהול הרשאות גישה באמצעות IAM תומכים ב-Agent Identity כדי לאפשר פיקוח חזק.

פרטי הכניסה של זהות הסוכן מאובטחים כברירת מחדל באמצעות מדיניות של בקרת גישה מבוססת-הקשר (CAA) שמנוהלת על ידי Google. המדיניות הזו אוכפת קישור mTLS כדי לוודא שאפשר להשתמש בפרטי הכניסה של הנציג, בצורה של אסימונים שמקושרים לאישור, רק מסביבת זמן הריצה המהימנה והמיועדת שלהם (לדוגמה, קונטיינר של Cloud Run). בזכות אמצעי האבטחה הבסיסי הזה, אי אפשר להשתמש בפרטי כניסה גנובים, וכך המשתמשים מוגנים מפני גניבת פרטי כניסה והשתלטות על החשבון (ATO).

בדף הזה מפורטים הנושאים הבאים:

מגבלות

אי אפשר להקצות לזהויות של סוכנים תפקידים של קטגוריות מדור קודם (storage.legacyBucketReader,‏ storage.legacyBucketWriter או storage.legacyBucketOwner) בקטגוריות של Cloud Storage.

יצירת סוכן עם זהות סוכן

כשיוצרים מופע של Agent Runtime, אפשר להקצות לסוכנים שפורסים ב-Agent Runtime זהות ייחודית. הזהות קשורה למזהה המשאב של הסוכן ב-Agent Runtime, והיא לא תלויה ב-framework שבו השתמשתם כדי לפתח את הסוכן.

כשיוצרים זהות של סוכן, יש את האפשרויות הבאות:

  • יצירת מכונה של Agent Runtime בלי לפרוס את קוד הסוכן: אם רוצים להגדיר כללי מדיניות של IAM לפני שפורסים את הסוכן, אפשר ליצור זהות של סוכן בלי לפרוס את קוד הסוכן. כדי לעשות את זה, יוצרים מופע של Agent Runtime עם השדה identity_type בלבד:

    import agentplatform
from agentplatform import types

client = agentplatform.Client(
  project=PROJECT_ID,
  location=LOCATION,
  http_options=dict(api_version="v1beta1")
)
remote_app = client.runtimes.create(
  config={
    "display_name": "identity-for-agent",
    "identity_type": types.IdentityType.AGENT_IDENTITY,
  },
)

    אחרי שיוצרים את המכונה של Agent Runtime עם זהות הסוכן, אפשר להוסיף קוד סוכן באמצעות client.runtimes.update(...).

  • יצירת מכונה של Agent Runtime בזמן פריסת קוד הסוכן: אם אתם רוצים להקצות את זהות הסוכן בזמן פריסת קוד הסוכן, אתם יכולים להשתמש ב-Agent Platform SDK for Python ובדגל identity_type=AGENT_IDENTITY.

    מגדירים את הסוכן במסגרת המועדפת:

    from google.adk.agents import Agent

agent = Agent(
    model="gemini-2.5-flash",
    name="minimal_agent",
    instruction="You are a helpful assistant.",
)

    לאחר מכן, פורסים אותו:

    import agentplatform
from agentplatform import types
from agentplatform.frameworks import AdkApp

# Initialize the Agent Platform client with v1beta1 API for agent identity support
client = agentplatform.Client(
  project=PROJECT_ID,
  location=LOCATION,
  http_options=dict(api_version="v1beta1")
)

# Use the proper wrapper class for your Agent Framework
app = AdkApp(agent=agent)

# Deploy the agent with Agent Identity
remote_app = client.runtimes.create(
  agent=app,
  config={
    "display_name": "running-agent-with-identity",
    "identity_type": types.IdentityType.AGENT_IDENTITY,
    "requirements": ["google-cloud-agentplatform[adk,runtimes]"],
    "staging_bucket": f"gs://"BUCKET_NAME",
  },
)

print(f"Effective Identity: {remote_app.api_resource.spec.effective_identity}")

    כאשר BUCKET_NAME הוא השם של הקטגוריה ב-Cloud Storage.

  • פריסת נציגים באמצעות Agents CLI: Agents CLI מתאים במיוחד ללומדים, ליצירת אב טיפוס ולבדיקה מהירה, כי הוא מציע פתרון פריסה מהיר עם משאבים בסיסיים למעקב. הפקודה הבאה פורסת את הנציג:

    agents-cli deploy --agent-identity

  • פריסת סוכנים עם Agent Identity באמצעות פריסת ADK: הגדרת הסוכן באמצעות ADK. לפני שמריצים את adk deploy, מריצים את הפקודות הבאות בתיקייה של הנציג כדי להוסיף קובץ תצורה עם זהות הנציג.

    # Create the file
$ touch .agent_engine_config.json

# Update the file to specify that you're using Agent Identity
$ echo '{ "identity_type": "AGENT_IDENTITY" }' > .agent_engine_config.json

מופע Agent Runtime נוצר עם זהות סוכן מאומתת על ידי המערכת, לקריאה בלבד (מזהה חשבון ראשי):

# Agent identity Format
principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME

# Example agent identity
principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/AGENT_ENGINE_ID

החלקים הבאים מוקצים לכם באופן אוטומטי כחלק מזהות הסוכן:

  • ‫TRUST_DOMAIN: כשמפעילים את Agent Platform API, מקבלים מתחם אמון:

    • אם יש לכם ארגון, מתחם האמון נוצר ברמת הארגון בפורמט agents.global.org-ORGANIZATION_ID.system.id.goog.

    • אם לפרויקט אין ארגון, נוצר מתחם אמון ברמת הפרויקט בפורמט agents.global.proj-PROJECT_NUMBER.system.id.goog.

  • ‫NAMESPACE: נתיב המשאב הבלתי ניתן לשינוי של הנציג.

  • ‫AGENT_NAME: הערך הבלתי ניתן לשינוי agent-reasoning-engine-id.

הזהות של הסוכן מבוססת על SPIFFE. אנחנו גם מקצים ומנהלים באופן אוטומטי אישור x509 בסוכן עם אותה זהות לאימות מאובטח. כברירת מחדל, לסוכן יש גישה ליומנים, למדדים, למודלים, לסשנים, לזיכרונות ולארגזי החול (גרסת טרום-השקה (Preview)) שלו.

זהויות של סוכנים מגיעות עם תפקידי ברירת מחדל של roles/aiplatform.agentContextEditor ו-roles/aiplatform.agentDefaultAccess, כדי שלסוכנים יהיו הרשאות בסיסיות לפעול.

אתם יכולים לראות את הזהות דרך מסוף Agent Runtime Google Cloud וה-API.

גישה Google Cloud לממשקי API ולשירותים באמצעות Agent Identity

אחרי שיוצרים נציג עם זהות נציג, אפשר לתת לנציג גישה לממשקי API ולשירותים של Google Cloud או לדחות את הגישה שלו אליהם באמצעות כללי מדיניות ה-IAM הבאים:

  • כללי מדיניות הרשאות: נותנים לסוכן גישה למשאב ב- Google Cloud .

  • כללי מדיניות דחייה: דחיית הגישה של נציג למשאב ב- Google Cloud .

איך נותנים גישה לסוכן

נותנים הרשאות IAM לזהות של הסוכן.

אנחנו ממליצים על התפקידים הבאים:

  • ‫roles/serviceusage.serviceUsageConsumer: נותנים לסוכן הרשאה להשתמש במכסה של הפרויקט וב-Agent Platform SDK.

  • ‫roles/browser: הענקת גישה לפונקציות Google Cloud בסיסיות.

  • ‫roles/secretmanager.secretAccessor: נותנים לסוכן גישה לסודות ב-Secret Manager. אם אתם מפנים לסודות כמשתני סביבה, אתם צריכים גם לתת את התפקיד roles/secretmanager.secretAccessor לסוכן השירות של Agent Platform‏ (service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com) כדי שהוא יוכל לאחזר את ערכי הסודות במהלך הפריסה.

יכול להיות שתצטרכו הרשאות נוספות אם אתם משתמשים ברישום ביומן, במדדים וב-Cloud API Registry, וגם לכל משאב אחר שאתם רוצים לחשוף לנציג. בהמשך מופיעות דוגמאות נוספות.

יוצרים מדיניות הרשאה ב-IAM כדי להקצות לסוכן תפקיד ב-IAM:

  # Example: Grant the agent access to vision API.
  gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
  --member="principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/AGENT_ENGINE_ID" \
  --role="ROLE_NAME" \

מחליפים את מה שכתוב בשדות הבאים:

  • ‫RESOURCE_TYPE: סוג המשאב (לדוגמה, projects או organizations).

  • ‫RESOURCE_ID: המזהה של המשאב שרוצים לתת אליו גישה.

  • ‫ORGANIZATION_ID: מזהה הארגון.

  • ‫PROJECT_NUMBER: מספר הפרויקט.

  • ‫LOCATION: האזור שלכם. האזורים הנתמכים בסביבת זמן הריצה.

  • ‫AGENT_ENGINE_ID: מזהה המשאב של המכונה של Agent Runtime.

  • ‫ROLE_NAME: שם התפקיד שרוצים לתת. לדוגמה, roles/vision.user. רשימה של תפקידים מוגדרים מראש מופיעה במאמר הסבר על תפקידים.

אחרי שמגדירים את IAM, פרטי הכניסה שמוגדרים כברירת מחדל לאפליקציה ב-SDK של Agent Platform משתמשים באופן אוטומטי בזהות של הנציג כדי לבצע אימות למשאבים ב-Google Cloud .

איך נותנים גישה להעברת סמכויות מסוכן לסוכן (A2A)

כשאתם מתכננים מערכת מרובת סוכנים שבה סוכן ראשי מפעיל סוכן משנה מרוחק שרשום ב-Agent Registry, לזהות של הסוכן הראשי צריכות להיות הרשאות לגלות את סוכן המשנה ב-Agent Registry ולהפעיל את נקודת הקצה שלו.

כדי לוודא שלזהות של הסוכן הראשי יש את ההרשאות הנדרשות כדי לגלות ולהפעיל סוכן משנה מרוחק, צריך לבקש מהאדמין להקצות את תפקידי ה-IAM הבאים לזהות של הסוכן הראשי:

  • כדי לאפשר לסוכן הראשי לחפש את נקודת הקצה של סוכן המשנה בזמן הריצה: צפייה ב-Agent Registry API (roles/agentregistry.viewer) בפרויקט הראשי או במשאב המרשם
  • מאפשרים לסוכן הראשי לשלוח הודעות לסוכן המשנה: משתמש בפלטפורמת הסוכנים (roles/aiplatform.user) במשאב של מנוע החשיבה הרציונלית של סוכן המשנה המטורגט

להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שהאדמין גם יוכל לתת לזהות של הסוכן הראשי את ההרשאות שנדרשות באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

לדוגמה, כדי להקצות את התפקיד roles/agentregistry.viewer בפרויקט, אתם יכולים להשתמש בפקודה הבאה של Google Cloud CLI:

gcloud projects add-iam-policy-binding PROJECT_NUMBER \
    --member="principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/PARENT_AGENT_ENGINE_ID" \
    --role="roles/agentregistry.viewer"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ORGANIZATION_ID: מזהה הארגון.
  • ‫PROJECT_NUMBER: מספר הפרויקט.
  • ‫LOCATION: האזור שבו פרוס הסוכן הראשי.
  • ‫PARENT_AGENT_ENGINE_ID: מזהה המשאב של המכונה של Agent Runtime של הסוכן הראשי.

איך נותנים גישה לכמה סוכנים

אתם יכולים להקצות תפקיד IAM לכל הסוכנים של Agent Runtime בפרויקט מסוים או בארגון כולו.

כדי להקצות תפקיד לכל הסוכנים של Agent Runtime בפרויקט, משתמשים באחת מהפקודות הבאות.

אם הפרויקט שייך לארגון:

# Grant all agents in a project the following role
gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role="ROLE_NAME"

אם הפרויקט לא שייך לארגון:

# Grant all agents in an orgless project the following role
gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
--member="principalSet://agents.global.proj-PROJECT_NUMBER.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role="ROLE_NAME"

כדי לפשט את הפריסות, אפשר לתת לכל הנציגים בפרויקט הרשאות נפוצות כמו מכסה, רישום ביומן או גישה למודלים. אחר כך, תנו הרשאות ספציפיות ומצומצמות לסוכנים מסוימים עבור הרשאות גישה למידע רגיש יותר, כמו גישה לנתונים. אפשר להעניק את ההרשאות האלה בכל שלב אחרי השימוש הראשון בתכונה "זהות הסוכן" בארגון או בפרויקט, כך שאפשר לעשות את זה לפני פריסת הסוכן.

לדוגמה, הפקודות הבאות מקצות תפקידים בסיסיים לכל הסוכנים בפרויקט:

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role=roles/serviceusage.serviceUsageConsumer

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role=roles/browser

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role=roles/cloudapiregistry.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role=roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platformContainer/aiplatform/projects/PROJECT_NUMBER" \
--role=roles/monitoring.metricWriter

כדי להקצות תפקיד לכל סוכני Agent Runtime בארגון:

# Grant all agents in an organization the following role
gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
--member="principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.platform/aiplatform" \
--role="ROLE_NAME"

איך נותנים גישה לשיחות בין סוכנים (A2A)

אם סוכן (סוכן א') צריך להפעיל סוכן אחר (סוכן ב'), אל תתנו לו הרשאות ברמת הפרויקט. במקום זאת, צריך להקצות תפקיד בהתאמה אישית שמכיל רק את aiplatform.reasoningEngines.query ו-aiplatform.reasoningEngines.get, שמקושר לנתיב המשאב של נציג ב'.

  1. יוצרים תפקיד בהתאמה אישית agentInvoker עם ההרשאות הנדרשות:

    gcloud iam roles create agentInvoker --project=PROJECT_ID \
  --permissions=aiplatform.reasoningEngines.query,aiplatform.reasoningEngines.get \
  --stage=GA

  2. מקשרים את התפקיד בהתאמה אישית למשאב של סוכן ב' כדי לתת גישה לזהות של סוכן א':

    gcloud beta ai reasoning-engines add-iam-policy-binding AGENT_B_ID \
  --region=LOCATION \
  --member="principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/AGENT_A_ID" \
  --role="projects/PROJECT_ID/roles/agentInvoker"

  3. כדי למנוע מזהויות של סוכנים לבצע פעולות ניהול רגישות בסוכנים אחרים, יוצרים מדיניות דחייה ב-IAM ל-reasoningEngines.create, ל-.delete ול-.update:

    deniedPrincipals:
  - principalSet://agents.global.org-ORGANIZATION_ID.system.id.goog/*
deniedPermissions:
  - aiplatform.googleapis.com/reasoningEngines.create
  - aiplatform.googleapis.com/reasoningEngines.delete
  - aiplatform.googleapis.com/reasoningEngines.update

דחיית בקשת גישה של סוכן

כדי למנוע מסוכן גישה למשאבים, אתם יכולים להשתמש במדיניות הדחייה של IAM או להגדיר מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

  • לדחות את הגישה של הנציג למשאבים מסוימים באמצעות מדיניות הדחייה של IAM.

    // Deny policy (deny all agents across the org from ability to create or delete buckets)

{
"displayName": "Deny access to bucket for all agent identities in the org",
"rules": [
  {
    "denyRule": {
      "deniedPrincipals": [
        "principalSet://<org.id>.global.agent.id.goog/*"
      ],
      "deniedPermissions": [
        "iam.googleapis.com/roles.create",
        "storage.googleapis.com/buckets.delete"
      ]
    }
  }
]
}

  • מגדירים בקרת גישה לישויות מורשות (PAB) כדי להגביל את המשאבים שהסוכן יכול לגשת אליהם, למרות הרשאות אחרות שיכולות להיות לסוכן:

    // PAB Policy (Only allow agents to operate within resource boundary)

{
    "name":"organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/example-policy",
    "details": {
    "rules": [
      {
        "description": "Restrict agent identity inside a folder",
        "resources": [
          "//cloudresourcemanager.googleapis.com/folder/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
  }
}

// Bind PAB policy to all identities in the organization (incl agent id)

gcloud iam principal-access-boundary-policies bindings create example-pab-binding \
      --organization=organizations/ORGANIZATION_ID \
      --policy=example-policy \ --target-principal-set=cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID

הנחיות ל-CI/CD ולאוטומציה

בצינורות עיבוד נתונים לפריסה אוטומטית שמוחקים ויוצרים מחדש סוכנים (כמו פריסות כחול-ירוק, סביבות בדיקה זמניות או תהליכי עבודה של Terraform), יכול להיות אובדן גישה שקט בזמן הריצה. בגלל שכל פריסה מחדש יוצרת משאב reasoningEngines חדש עם מזהה ייחודי, הסוכן מקבל מזהה חשבון משתמש חדש. החשבון החדש לא יקבל בירושה את הרשאות ה-IAM שניתנו לחשבון הקודם.

כדי לנהל את ההרשאות בצינורות עיבוד נתונים אוטומטיים, השתמשו באסטרטגיות הבאות:

  • אחזור דינמי של מזהה חשבון המשתמש החדש: מתעדים את הערך של spec.effectiveIdentity מהתגובה לפריסה, או שולחים שאילתה ל-API בארכיטקטורת REST אחרי הפריסה כדי לקבל את הזהות הפעילה של הסוכן. אחרי הפריסה, צריך להחיל את קישורי ה-IAM הנדרשים על חשבון המשתמש החדש.

    לדוגמה, אפשר לשלוח שאילתה לגבי הזהות הפעילה באמצעות gcloud, בעזרת הפקודה הבאה:

    gcloud ai reasoning-engines describe RESOURCE_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --format="value(spec.effectiveIdentity)"

    ב-Terraform, אתם יכולים ליצור באופן דינמי את חשבון המשתמש של זהות הסוכן ממזהה המשאב של google_vertex_ai_reasoning_engine שנפרס, ולהפנות אליו בקישורי IAM:

    resource "google_vertex_ai_reasoning_engine" "reasoning_engine" {
  provider = google-beta

  project      = var.project_id
  region       = var.region
  display_name = var.display_name
  description  = var.agent_description

  spec {
    agent_framework = "google-adk"
    identity_type   = "AGENT_IDENTITY"

    source_code_spec {
      inline_source {
        source_archive = filebase64(data.archive_file.agent_tarball.output_path)
      }

      python_spec {
        entrypoint_module = var.agent_python_spec.entrypoint_module
        entrypoint_object = var.agent_python_spec.entrypoint_object
        requirements_file = var.agent_python_spec.requirements_path
        version           = var.agent_python_spec.version
      }
    }

    deployment_spec {
      env {
        name  = "GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY"
        value = "true"
      }

      env {
        name  = "OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT"
        value = "true"
      }
    }
  }
}

locals {
  agent_resource_id        = element(split("/", google_vertex_ai_reasoning_engine.reasoning_engine.id), -1)
  agent_identity_principal = "principal://agents.global.org-${data.google_organization.org.org_id}.system.id.goog/resources/aiplatform/projects/${data.google_project.project.number}/locations/${var.region}/reasoningEngines/${local.agent_resource_id}"
}

  • שימוש ב-principalSets ברמת הפרויקט להרשאות בסיסיות: מכיוון שקישורי principalSet מטרגטים את כל הנציגים בפרויקט, הם נשארים גם אם מוחקים את הנציג ויוצרים אותו מחדש. מקצים תפקידים נפוצים ולא רגישים (כמו שימוש בשירות, רישום ביומן והסקת מסקנות כללית ממודלים) לprincipalSet ברמת הפרויקט, במקום לישויות מורשות של סוכנים ספציפיים. הגבילו את הקישורים של principal:// למקורות מידע רגישים מאוד.

תיעוד הפעילות של סוכן Logging

אם תפעילו את Cloud Logging, תוכלו לצפות ביומנים כדי לראות אילו סוכנים ומשתמשים ניגשו למשאב Google Cloud .

  • כשהסוכן פועל בשם המשתמש, ביומנים מוצגות הזהויות של הסוכן ושל המשתמש.

  • כשהסוכן פועל לפי ההרשאות שלו, ביומנים מוצגת רק הזהות של הסוכן.

רשימת הסוכנים והזהויות שלהם

אתם יכולים לראות את רשימת הזהויות של הנציגים ב-Agent Runtime באמצעות מסוף Google Cloud ושורת הפקודה.

המסוף

  1. במסוף Google Cloud , נכנסים לדף Deployments ב-Agent Platform.

    מעבר אל Deployments

    ברשימה מופיעים הסוכנים שנפרסו בפרויקט שנבחר. אפשר להשתמש בשדה Filter כדי לסנן את הרשימה לפי העמודה שציינתם.

  2. הזהות של כל סוכן מופיעה בעמודה Identity.

‫API בארכיטקטורת REST

אתם יכולים לאחזר את זהות הסוכן כשאתם מקבלים מכונה של Agent Runtime באמצעות ה-API בארכיטקטורת REST.

התשובה כוללת את זהות הסוכן בפורמט הבא:

{
  ...
  spec: {
    "effectiveIdentity": "agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_ID/locations/LOCATION/reasoningEngines/AGENT_ENGINE_ID"
  }
  ...
}

במכונות של Agent Runtime שלא משתמשות בזהות של הסוכן, השדה effectiveIdentity מכיל את השם של סוכן השירות או של חשבון השירות שמשויך למכונה של Agent Runtime.

ביטול ההצטרפות לבקרת גישה מבוססת-הקשר (CAA)

כברירת מחדל, אם מנסים להשתמש בטוקן גישה מחוץ לסביבת זמן הריצה של Agent Runtime, מתקבלת השגיאה הבאה:

Error Code: "401"
Error Details: "Context-Aware Access requirements are not met"

במקרים חריגים, כמו דרישות ספציפיות לשיתוף טוקנים בין סוכנים, אתם יכולים לבטל את ההסכמה למדיניות ברירת המחדל של CAA. אנחנו ממליצים מאוד לא לעשות את זה, כי זה חושף את הנציג לגניבת פרטי כניסה.

כדי לבטל את ההצטרפות למדיניות ברירת המחדל של בקרת גישה מבוססת-הקשר (CAA), מגדירים את משתנה הסביבה הבא כשיוצרים את המכונה של Agent Runtime:

config={
  "env_vars": {
    "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
  }
}

המאמרים הבאים

מדריך

איך מנהלים סוכנים שנפרסו בסביבת זמן הריצה המנוהלת של Agent Platform.

מדריך

שימוש בסוכן עם Agent Platform Runtime.