Agentic AI FactoryGitHub

Self-Service docs

Build

Enterprise Platform Capabilities

Rendered from Agentic-ai-self-service/docs/ENTERPRISE_CAPABILITIES.md

View source on GitHubProject page

The enterprise feature set layered on top of the core canvas — lifecycle, governance, integration, and FinOps capabilities, each wired end-to-end (UI → API → Step Functions / store → AWS).

← Back to README

Beyond the core canvas, the platform layers an enterprise feature set on top of raw AgentCore primitives. Each capability is wired end-to-end (UI → API → Step Functions / store → AWS) and owner-scoped for multi-tenant safety.

Agent lifecycle & quality

  • Mandatory production safety profile -- Production-like deploy admission injects a platform-managed production-v1 Bedrock Guardrail before any side effect. All content and prompt-attack filters are floored at HIGH; credential/common-PII entities are anonymized unless the caller requests stronger blocking; custom policies stay additive. Mutable existing Guardrails are outside the production support envelope until policy-version attestation exists. Generated Runtime agents keep model input/output redaction on and Guardrail trace off so original matched sensitive content cannot reappear in traces. They also call ApplyGuardrail fail closed around every tool boundary: Strands BeforeToolCallEvent blocks unsafe arguments before execution, AfterToolCallEvent replaces unsafe results before model consumption, and direct Converse/code-interpreter paths use the same wrapper. Screening failure, malformed response, oversized content, or unavailable hooks deny rather than bypass; Guardrail runs before HITL. Managed Harness is development-only because its current API has no native model Guardrail field and its documented after-tool/after-invocation hooks cannot retract completed results or streamed output. Every production tool Gateway also receives a managed Cedar configuration (ENFORCE, fail closed) at API admission and again in the Policy step; disabled/LOG_ONLY settings cannot weaken it. Production tool planes require AgentCore Gateway because LiteLLM cannot attach AgentCore Policy; model-only agents need no policy engine. Runtime and Harness execution roles—including dynamic, per-agent, shared CDK, and exported CloudFormation roles—carry an explicit deny for Gateway/target/Policy control-plane mutations, and builders fail closed on exact or wildcard allows that match those actions. The production evaluation gate likewise cannot be disabled by CDK context or Lambda environment configuration.
  • Agent Versioning, evaluated promotion & rollback -- Every deploy is an immutable, versioned snapshot. A runtime has production / staging slots; GET /api/runtimes/{name}/versions lists history. Dev-like environments preserve direct production for iteration. Staging/prod-like environments land new versions in staging and reject direct production before any row, secret, or AWS resource is created. Production promotion requires a server-started AgentCore batch evaluation over at least five exact staging sessions, with the frozen platform evaluator/threshold policy. The backend validates the terminal service result, source runtime, session counts, failures, scores, timestamps, account and Region, writes one digest-bound immutable attestation, then condition-checks that evidence in the same DynamoDB transaction that moves the production pointer. The browser never supplies a verdict or score. POST .../rollback can restore only the exact previous production pointer as a separately fenced emergency path.
  • Cedar ENFORCE policy enforcement (fail-closed, converge-in-place) — When a Policy node runs in ENFORCE mode, the policy step builds a schema-correct Cedar policy set against the gateway's real MCP tool manifest: one permit(principal is AgentCore::OAuthUser, action in [AgentCore::Action::"{Target}___{tool}", …], resource == AgentCore::Gateway::"<arn>") over the allowed tools (the action in [...] list form is mandatory even for one tool — a singleton action == "X" is rejected as "Overly Permissive"), with forbidden tools denied by omission (AgentCore is default-deny; ENFORCE also filters tools/list so a forbidden tool is invisible to the agent). Several guards keep enforcement honest: (1) policy names are engine-prefixed to avoid a name-collision pitfall — AgentCore policy names are account-global, not engine-scoped; (2) on a name conflict the step recovers the existing policy from this engine and validates it, or aborts if the name belongs to a foreign engine; (3) it never reports success on an engine holding 0 ACTIVE policies. A freshly-created policy engine + gateway take ~20–60 minutes (variable, AgentCore-side) to become consistent (create_policy/update_policy end CREATE_FAILED/UPDATE_FAILED "Insufficient permissions to call gateway" until then), too long to block the deploy. So the step attaches the engine fail-closed in ENFORCE with the permit recorded as enforce_pending — default-deny leaves tools temporarily unavailable rather than unprotected (a forbidden-tool value must never leak) — and a shared _maybe_promote_policy() converges the permit to ACTIVE on each invoke/status touchpoint once the gateway settles. The promoter recovers a failed permit in place via update_policy (stable policy id — NOT delete+recreate, which raced concurrent status-poll invocations on the account-global name and never converged), skips in-flight (CREATING/UPDATING) policies, and treats ConflictException as a benign concurrent-run signal. update_policy's description is a {"optionalValue": str} structure (not a bare string like create_policy). Requires bedrock-agentcore:UpdatePolicy on the deployment Lambda role. State is surfaced via policy_result.{mode,enforce_validation_pending,promoted_at_first_use}. Verified live: post-convergence tools/list returns only permitted tools, permitted tools return data, forbidden tools are denied; the policy engine is torn down children-first on delete.
  • Evaluation Framework -- Register AgentCore Online Evaluation (built-in goal-success / correctness / helpfulness evaluators) at deploy time and aggregate recent scores through GET /api/runtimes/{name}/evaluations. Production-like environments additionally use AgentCore Batch Evaluation as a fail-closed release gate: scenario ground truth and expected trajectories are evaluated against the exact staging Runtime; missing, stale, partial, failed, ignored, low-score, wrong-account, wrong-Region, or wrong-runtime evidence cannot move the production slot.
  • Observability Dashboard -- Each deploy upserts a per-runtime CloudWatch dashboard (latency, invocations, errors, token usage, tool-call success). GET /api/runtimes/{name}/dashboard-url returns the deep link. Platform Lambdas and deployed agents both emit OTLP spans (see Observability).
  • Cost analytics & atomic invocation authorization -- GET /api/runtimes/{name}/cost prices observed gen_ai.usage.* token counts against the pinned Bedrock table. Production-mediated slot, direct, stream, MCP, and trigger dispatches also require an owner/agent/tag limit and atomically reserve one configured USD-denominated authorization unit across every applicable monthly counter before Runtime network dispatch. Exact 429/Retry-After exhaustion and pre-dispatch 503 storage failure are fail closed; dispatched/unknown calls commit conservatively. Authorization units are not actual AWS charges or an account bill cap.

Authoring & reuse

  • NL Agent Generator (describe → canvas) -- POST /api/generate-canvas turns a natural-language description into a validated canvas spec via Bedrock tool-use (two-turn: clarify → generate). Generated tools are constrained to real built-in tool IDs (or custom tools with an input schema) so a generated agent always deploys with working gateway targets.
  • Agent Registry with two-persona approval -- An org-wide catalog to publish, discover, and clone agents as reusable blueprints. Role-based via Cognito groups: a registry-developer publishes (entry enters pending), browses approved entries, and clones approved/own entries — but cannot approve; a registry-admin sees the pending-review queue, approves/rejects submissions, and can delete any entry. Publish from the Deploy panel; browse/clone from the canvas. See Registry Roles & Approval.
  • Prompt Library -- Versioned, reusable system prompts (/api/prompts) with version history, a promotable default version, and resolve-by-reference at codegen time. A runtime's systemPrompt can be an inline string or a {prompt_id, version_id?} reference.
  • Python Code Export ("eject") -- POST /api/export-python returns a standalone, runnable Python project (agent.py, requirements.txt, Dockerfile, run.sh, .env.example, README) so an agent can run independently of the platform. (Companion to the existing CloudFormation export.)

Integration & automation

  • External browser SDK and chat Web Component -- Every production frontend ships /agentcore-chat-v1.js plus declarations. AgentCoreClient and <agentcore-chat> accept a host-provided short-lived access-token callback, use credentials=omit, never persist tokens or auto-retry POSTs, and call only the stable production alias (POST /api/runtimes/{name}/invoke). The alias delegates to the existing exact slot/version/deployment target resolver, budget, OBO, Guardrail, Cedar, and audit path and rejects caller-supplied staging/runtime/account authority. Shadow DOM renders model output with textContent; CloudFront permits non-credentialed cross-origin module/API use while retaining frame-ancestors 'none' because no iframe is used.

  • A2A (Agent-to-Agent) -- Development environments can deploy a runtime that serves a /.well-known/agent-card.json and exposes an SSRF-guarded call_a2a_peer tool (HTTPS-only, host allowlist + IP denylist). Production admission refuses A2A before side effects because direct inbound and nested peer Runtime calls do not yet propagate atomic invocation reservations; presenting it as covered would make the authorization ceiling bypassable.

  • Per-Agent Identity -- Opt-in identityConfig.mode=per_agent mints a distinct least-privilege IAM execution role scoped to exactly the resources an agent is wired to (vs the shared demo role). Roles are tagged ManagedBy=agentcore-flows so cleanup is tag-scoped.

  • Agentic Retrieval -- Knowledge Base nodes support retrievalStrategy of multi_hop (LLM query decomposition + iterative retrieve), hybrid (vector + keyword, with managed-KB fallback to semantic), or reranked (wide retrieve + Claude-judge reorder) beyond simple retrieval.

  • Durable runtime triggers -- Provision cron, eventbridge, s3, or webhook triggers on an owned runtime (/api/runtimes/{name}/triggers). The target is derived server-side and pinned to the exact production deployment. Scheduled and event-driven triggers use stack-tagged EventBridge rules feeding an encrypted SQS queue with a DLQ. Signed webhooks conditionally claim the authenticated delivery ID before enqueue: the first request returns duplicate=false, a durable seven-day QUEUED marker binds the delivery ID to the request-body SHA-256 and makes byte-identical replay return duplicate=true without another send; reuse with different authenticated bytes returns 409. A 60-second lease recovers crashes, and known enqueue failure releases for retry. Worker-side transactional delivery claims remain the second idempotency layer for ambiguous SQS sends and fence runtime teardown. Optional callbacks are HTTPS-only and DNS-rebinding resistant; trigger deletion purges both marker types after proving live resource ownership. The webhook signing secret is disclosed only in the no-store create response, and S3 source buckets must have EventBridge notifications enabled.

  • SaaS Connectors (live OpenAPI Gateway targets) -- A curated catalog (Jira/AtlassianOauth2 + API-key Basic, Asana/PAT, Slack, GitHub, Salesforce) plus a generic OpenAPI/MCP connector, deployable as real Gateway targets. The deploy step fetches the connector's OpenAPI spec (SSRF-guarded, host-allowlisted), registers an API-key or OAuth2 client-credentials credential provider backed by an owner-scoped Secrets Manager secret, and attaches it to the gateway target. OpenAPI targets are crawled (not inline) and readiness is verified by probing the gateway's live MCP tools/list. GET /api/connectors lists the catalog for discovery. Teardown deletes the target, credential provider, and secret via the resource manifest. Live-verified: GitHub (api-key → real /user login) and Asana (PAT → real /users/me) end-to-end; Jira/Slack/Salesforce require live credentials to exercise.

  • GitOps Sync -- Store a Git PAT in an owner-scoped Secrets Manager namespace (/api/workflows/{id}/git-token) and pull a workflow spec from a repo (/api/workflows/{id}/git-sync), preserving id/owner/ACL. SSRF-guarded.

  • Human-in-the-Loop (HITL) -- Inject a human_approval tool into an agent; pending approvals land in an owner-scoped queue (GET /api/hitl/pending, POST /api/hitl/{id}/decision) surfaced in the UI inbox.

  • Team Workspaces & Sharing -- Share a workflow with viewer/editor roles (/api/workflows/{id}/share); list workspace-visible workflows (GET /api/workspaces). Owner-only mutation with escalation guards.

Enterprise governance & operations (Loom-inspired)

An enterprise governance layer modeled on awslabs/loom — scope-based access control, least-privilege automation, private networking, config-driven human oversight, and FinOps self-drive. Each item is wired end-to-end and verified against real AWS.

  • Scope-based RBAC/ABAC -- Two-dimensional authz from Cognito groups: tenant role (t-admin/t-user) × resource groups (g-admins-*/g-users-*) → a scope set; require_scopes() guards every write route. Advisory by default (RBAC_ENFORCE=false: log-would-deny), flips to fail-closed 403. Scopes never bypass owner_sub tenant isolation. See RBAC Rollout.
  • 3rd-party OIDC IdP federation -- Context-gated Cognito identity provider federates an external IdP (e.g. Okta) and maps its group claim into the platform's internal group model, so federated users inherit RBAC scopes without a separate platform account (-c oidc_client_id=… -c oidc_groups_claim=groups).
  • JIT least-privilege permission requests -- POST /api/permissions/requests files a scoped IAM-widening request. Approval conditionally claims PENDING → APPLYING with a five-minute token before the deterministic JIT-{id} PutRolePolicy; rejection is permitted only from PENDING, so a permission that may have landed cannot be recorded rejected. Definitive IAM refusals release back to PENDING; timeout/transport ambiguity stays APPLYING, remains visible in the admin queue, and can be idempotently reclaimed after lease expiry before finalizing APPROVED. Requests are limited to non-shared platform AgentCore* roles, validated ARNs/read-only wildcard resources, and an action allowlist that rejects iam:, sts:, *, plus exact or wildcard Gateway/target/Cedar control-plane mutations.
  • Config-driven HITL approval policies -- /api/settings/approval-policies define glob-matched tool/action rules (require block vs notify). On deploy, enabled policies serialize into the runtime's LOOM_APPROVAL_POLICIES env var so a guaranteed BeforeToolInvocation hook forces approval on matching tools — independent of whether the model chooses to call human_approval. Applies to both codegen and managed-harness runtimes.
  • OBO identity propagation & inspection -- GET /api/identity/token-info decodes the caller JWT (issuer/scopes/claims) for the UI; POST /api/identity/test-obo validates an RFC 8693 on-behalf-of exchange config (TOKEN_EXCHANGE / JWT_AUTHORIZATION_GRANT) without a live user token. A connector with delegationMode=obo binds Gateway to the platform workforce issuer/client and exact deployment-owner sub. The API rechecks those claims plus token type/expiry, reserves invocation capacity, and invokes the exact production Runtime through target-account SigV4. The workforce JWT is signed into AgentCore's allowlisted custom-header namespace for request-local Gateway exchange; Runtime has no bearer authorizer, so a user cannot bypass platform admission by invoking it directly. Generated agents close the request-local MCP client on every path and never fall back to M2M. Non-credential identityEvidence must match the same subject, issuer, and expiry; a downstream whoami attestation remains the first-live-call gate before promotion.
  • VPC-egress runtimes & named profiles -- /api/settings/vpc-profiles define reusable {subnet_ids, security_group_ids} bundles; a deploy referencing one by name (vpcProfile) threads networkMode=VPC into the runtime so it runs in customer private subnets. Unknown profile → 400 at deploy. Optional PrivateLink ingress IaC (NLB + VPCEndpointService + SG) ships as a downloadable add-on (privatelink-ingress.yaml).
  • Import existing runtime by ARN -- POST /api/runtime/import adopts an externally-built AgentCore Runtime as a caller-owned deployment (no codegen/deploy) so pre-existing runtimes join the platform's version/slot/cost/observability surfaces.
  • Integration gating -- When AWS Agent Registry federation is enabled, a deploy referencing an MCP/A2A integration is rejected unless each referenced integration is APPROVED in the registry (no-op when federation is off).
  • AWS Agent Registry federation -- Opt-in federation of deployed agents into the org-wide AWS-native Agent Registry (CreateRegistryRecord → SubmitRegistryRecordForApproval → approve → SearchDiscoverableRegistryRecords), auto-registered on deploy and removed on teardown. Targets the GA API: Agent Registry is its own AWS service (agent-registry-control / agent-registry clients, agent-registry:* IAM actions, recordType ∈ MCP|AGENT|CUSTOM|SKILL), so the backend requires boto3 >= 1.43.66. GET /api/registry/aws-config reports sdk_supported: false on an older bundle rather than silently degrading.
  • Invocation authorization + scheduled FinOps reconciliation -- /api/cost/budgets defines owner/agent/tag monthly limits. Production requires a match and atomically reserves one BUDGET_RESERVATION_USD unit across all applicable counters before each slot/direct/stream/MCP/trigger invocation operation; a bounded MCP handshake plus tool call is one operation, and concurrent reserved plus committed units cannot cross a definition. Failures after the first dispatch and one-hour unknowns commit conservatively; only proven pre-dispatch failures release. A daily sweep also prices month-to-date observed usage and emits BudgetBreach for warn/over. The unit is admission capacity, not an exact-cost or account-bill cap; downstream vendor/tool charges and separately credentialed calls remain outside it. Production A2A is refused until reservation propagation exists.
  • Live model catalog -- GET /api/models discovers text models live from Bedrock (list_inference_profiles + list_foundation_models, filtered to TEXT/ACTIVE/ON_DEMAND) merged with a curated friendly-label overlay, replacing the hardcoded picker; falls back to a static list if Bedrock is unreachable.
  • Append-only audit & admin analytics -- Both API Lambdas classify every write route. Production conditionally appends a correlated intent before route execution and refuses the write if evidence storage is unavailable; a separate immutable outcome row records the result. Lambda IAM permits append/query only and explicitly denies updates, deletes, and batch writes. Canonical SHA-256 digests are verified on read, new production events omit TTL, legacy rows without digests are marked unverified, and missing outcomes surface as incomplete attempts in GET /api/admin/audit and the UI. This is tamper-evident within the platform IAM boundary, not an Object Lock/WORM claim against account administrators. Analytics retain by_action/by_actor, distinct actors/sessions, and by_day.
  • End-user Chat persona + admin View-as -- Consumer personas (t-user) get a streaming ChatPage instead of the builder canvas; admins get the builder and can preview the consumer experience. Persona derives purely from Cognito group scopes — no privilege change.
  • Multi-region / multi-account deploy (opt-in) -- Off by default; when enabled, a region allowlist + cross-account sts:AssumeRole into a name-scoped AgentCoreFlowsDeploymentRole (with a dry-run identity check) lets a deploy land in a registered target account.
  • Non-Bedrock provider credentials -- Selecting a credentialed provider (OpenAI/Anthropic/Gemini/LiteLLM/Mistral/Groq/DeepSeek/Together/Writer) stores a tenant-bound source under agentcore-provider/*. Deployment validates its live owner/stack tags, copies the raw value into an exact deployment-bound agentcore-connector/* secret in the selected target account, and gives the runtime only that ARN (PROVIDER_API_KEY_SECRET_ARN, optional PROVIDER_BASE_URL). Plaintext is never placed in runtime environment variables or Step Functions history.
  • Customer-resource authority boundary -- Existing Knowledge Bases, S3/S3 Vectors stores, OpenSearch Serverless collections, Aurora clusters, transformation Lambdas, KMS keys, and KB credential sources are not authorized by a pasted ARN. The resource owner must opt in with AgentCoreFlowsAccess=allow (optionally caller-scoped by OwnerSubHash), the deploy step re-reads the live resource before any IAM mutation, and customer credential values are copied into deployment-bound target-account secrets. Same-name platform resources require exact stack + deployment + caller binding before reuse.
Back to top