One governed source compiles domain/content policies for Verified Permissions and tool policies for AgentCore Policy.
One trust boundary. Many AI surfaces.
Build one identity-bound, rights-aware decision path for applications, RAG, lineage triage, developer IDEs, MCP tools, A2A agents and external assistants. Promote capabilities by risk tier rather than exposing every pathway equally.
Vector RAG, GraphRAG and operational lineage remain distinct evidence classes with explicit confidence and provenance.
MCP, A2A, HTTP, AG-UI and OpenLineage connect through the same identity, rights, safety and audit core.
Internal read pathways can ship first. Writes, delegation, public assistants and commerce advance through stronger gates.
Each manifest binds exposure, identity, protocols, actions, data scope, policy bundles, retrieval route, models, guardrails, evaluations, budgets and audit retention.
Enterprise SSO, rights-filtered retrieval, resource authorization, citations and immutable evidence.
Explicit confirmation, rollback, narrow tools, delegation limits, sandboxing and human review.
OAuth 2.1, privacy and licensing review, abuse controls, public testing, support and merchant-owned entitlement.
Four decisions. Four owners.
The platform remains governable when authentication, authorization, content rights and AI safety are modeled as separate decisions with independent evidence.
Authentication
Question: Who is making the request?
Enterprise OIDC. Durable subject ID. Tenant. Session assurance. Authentication time.
Authorization
Question: May this principal perform this platform action?
Amazon Verified Permissions. Cedar policies. Default-deny. Explicit action and resource.
Content rights
Question: May this principal use this asset now, here and for this purpose?
Entitlement, subscription, time window, country, classification and derivative-use terms.
AI safety
Question: Is this input, retrieved context, action or output acceptable?
Guardrails, schema validation, sanitizers, prompt-injection defenses and evaluations.
Models generate content. They never authorize access. Primary security invariant
Fail closed
Deny when identity, tenant, rights, policy version, geography or required safety enforcement cannot be established.
No direct provider access
Applications do not receive broad model invocation permissions. The governed gateway is the approved invocation boundary.
One core. Multiple governed pathways.
The architecture separates client protocols and execution targets from identity, rights, safety, risk classification and evidence. A pathway manifest selects the controls required for each exposure and capability.
Decision plane
Identity normalization, pathway risk, domain authorization, tool authorization and rights resolution remain deterministic.
Execution plane
RAG engines, models, tools and agents are replaceable targets selected only after policy and safety decisions.
Evidence plane
Every decision carries policy, content, route, delegation, guardrail, evaluation and cost provenance.
Verified Permissions remains the business-domain and content-rights authority. AgentCore Policy enforces tool-level requests at AgentCore Gateway. Both derive from one governed policy model and publish correlated decision evidence.
Exposure changes the control set.
Risk is determined by identity, data sensitivity, autonomy, reversibility, external exposure and economic consequence—not by the model name. These tiers are a platform overlay informed by AWS, NIST and OWASP guidance; they are not official AWS tier labels.
Public curated facts
Static public metadata, approved abstracts, documentation and discovery endpoints.
Internal identity-bound read
Knowledge retrieval, lineage inquiry, observability summaries and developer assistance.
Internal reversible action
Drafting, ticket creation, non-production changes and reversible workflow steps.
Privileged or delegated autonomy
Production tools, A2A task delegation, sensitive data and multi-step action chains.
External authenticated pathway
Partner agents, public MCP, external assistant apps and premium content retrieval.
Economic or irreversible action
Payments, purchases, publication, destructive change or high-impact decision.
Entitlement is data, not code.
Premium access, person-specific grants, embargoes, time windows, purpose limits and geographic restrictions should be editable as rights data and policy.
| Rights dimension | Example attribute | Enforcement |
|---|---|---|
| Identity | allowedPrincipalIds, groups, tenant | Per-resource Cedar decision |
| Subscription | minimumSubscription = premium | Policy plus entitlement record |
| Time | validFrom, validUntil, embargo | Signed request time in context |
| Geography | Allowed and denied countries or legal regions | Signed edge context, rechecked at origin |
| Purpose | Support, research, summary, publication | Explicit action and request purpose |
| AI usage | Retrieval, summarization, transformation, training | Separate rights flags and actions |
| Output | Maximum excerpt length, citation requirement | Prompt and response post-processing |
export interface ContentRights {
contentId: string;
contentVersion: string;
tenantId: string;
classification: "public" | "internal" | "confidential" | "restricted";
requiredEntitlement?: string;
minimumSubscription: "free" | "standard" | "premium" | "enterprise";
allowedPrincipalIds?: string[];
allowedGroups?: string[];
allowedCountries?: string[];
deniedCountries?: string[];
validFromEpoch?: number;
validUntilEpoch?: number;
allowedPurposes: string[];
aiRetrievalAllowed: boolean;
summarizationAllowed: boolean;
derivativeGenerationAllowed: boolean;
modelTrainingAllowed: boolean;
maximumExcerptCharacters?: number;
policyVersion: string;
}
Use filters to reduce the candidate set. Load authoritative metadata and authorize each returned content resource before it enters a prompt.
Authorize before context becomes capability.
Every request follows the same order. Each stage emits enough evidence to explain why the final response was allowed, constrained, blocked or denied.
Strip spoofable headers. Verify signature, key ID, issue time, expiry and request binding.
Convert provider claims into a stable platform principal. Email is not the durable key.
Evaluate principal, tenant, purpose, subscription, country and application against Cedar policy.
Enforce schema, size, Unicode, secret, PII, content and prompt-injection controls before retrieval.
Metadata narrows candidates. Per-resource authorization remains the final boundary.
Resolve a capability alias to an approved provider, model, region, quota and guardrail version.
Recheck safety, structured output, URLs, citations, data leakage and rights-dependent excerpt limits.
Record decision provenance, content IDs, policy hashes, model route and usage without default raw-content logging.
One policy model. Two enforcement targets.
Use the service best aligned to each decision while preserving a single semantic model, shared tests and correlated evidence. Verified Permissions handles domain and resource rights. AgentCore Policy handles AgentCore Gateway tool requests and input parameters.
Verified Permissions
Authoritative for application actions, tenant isolation, premium entitlement, content rights, time, geography, purpose and per-resource decisions.
AgentCore Policy
Authoritative at AgentCore Gateway for whether an OAuth user or IAM entity may invoke a specific tool with specific input parameters.
Do not manually maintain overlapping Cedar policies in separate repositories. Compile both targets from common entities, actions, context vocabulary and test fixtures. Reject releases when equivalent decisions diverge.
Promotion is a tested product decision.
A pathway release packages policy bundles, exposure tier, protocol scopes, retrieval route, model aliases, guardrails, budgets and evaluation evidence. Code deployment is only one component.
Policy release
Strict schemas, common fixtures, differential tests and correlated domain/tool decision evidence.
Operational configuration
AppConfig for routes, quotas, residency, feature flags, staged rollout, alarms and emergency kill switches.
Evaluation release
Pin datasets, judges, thresholds and expected policy outcomes so the release can be replayed and audited.
Select retrieval by evidence shape.
No single RAG engine is optimal for every question. Route according to document structure, relationship depth, freshness, query determinism, metadata volume, latency, residency and authorization requirements.
| Path | Best fit | Strengths | Material constraints | Governance posture |
|---|---|---|---|---|
| Bedrock KB + OpenSearch Serverless | General enterprise document RAG and hybrid search | Mature filtering, hybrid retrieval, managed Bedrock integration | Higher standing cost; index and metadata design still matter | G1 internal-ready after per-resource authorization |
| Bedrock KB + S3 Vectors | Cost-sensitive large vector corpora and less frequently queried knowledge | S3-native economics and managed KB path | Metadata limits affect rights-filter design; validate latency and region support | G1 when rights attributes fit or are resolved authoritatively after retrieval |
| Bedrock KB + Aurora pgvector | Teams needing relational joins, transactional metadata or PostgreSQL control | SQL ecosystem and data co-location | Capacity, indexing, vacuuming and connection management | G1 with database and application authorization aligned |
| Kendra GenAI index | Enterprise search with connectors, relevance and document ACL patterns | Search-oriented retrieval and enterprise sources | Different customization and cost model; confirm ACL semantics | Use ACL filtering plus gateway resource authorization |
| Structured KB / Redshift | Natural-language access to governed warehouse facts | GenerateQuery converts questions to SQL-like retrieval | Redshift-only managed path; generated query validation and cross-region processing require review | G1 read-only first; enforce row/column rights and query budgets |
| Neptune Analytics GraphRAG | Multi-hop concepts and inferred relationships across documents | Managed semantic graph construction and graph-enhanced retrieval | S3 source and graph lifecycle constraints; generated relationships are probabilistic | Use as retrieval evidence, never authoritative lineage |
| Customer-managed retriever | Unsupported stores, bespoke ranking, strict latency or domain algorithms | Maximum control and portability | Highest engineering, security, evaluation and operations burden | Require the same pathway contract and audit schema |
Evaluate retrieval separately
Measure recall, precision, rights-filter correctness, latency and route selection before generation quality obscures retrieval errors.
Use direct ingestion deliberately
Direct document APIs can support event-driven freshness, but the platform must preserve rights metadata, deletion and lineage semantics.
Pin query behavior
Version filters, rerankers, chunking, embeddings, prompts and citation checks as part of the pathway release.
Separate recorded provenance from inferred explanation.
Operational lineage is authoritative evidence about datasets, jobs, runs and transformations. GraphRAG may enrich that evidence with owners, runbooks and prior incidents, but inferred semantic edges must remain visibly lower confidence.
Authoritative facts
OpenLineage events, DataZone or Unified Studio lineage nodes, run history, deployed schemas, data quality and observed incidents.
Derived analysis
Blast radius, temporal correlation, likely root-cause candidates and missing-lineage gaps. Label as inference with confidence.
Semantic enrichment
GraphRAG over runbooks, architecture records and prior incidents can explain context without rewriting operational truth.
| Tool | Risk | Required result contract | Readiness |
|---|---|---|---|
| lineage.resolve_asset | G1 | Canonical asset IDs, environment, owner and ambiguity set | Internal-ready |
| lineage.trace_upstream / downstream | G1 | Authorized nodes, edge type, event time, source and completeness | Internal-ready |
| lineage.compare_at_time | G1 | Historical graph delta with versioned event evidence | Internal-ready |
| lineage.get_quality_signals | G1 | Quality rule results, period, metric source and freshness | Internal-ready |
| lineage.simulate_change_impact | G2 | Predicted impact, assumptions, uncertainty and affected owners | Controlled pilot |
| lineage.remediate | G3 | Explicit plan, approvals, dry run, idempotency and rollback | Controlled pilot |
The governed pathway must apply its own tenant, asset and purpose authorization before exposing catalog lineage through an LLM or agent, even when the caller can technically invoke a catalog API.
Protocols describe interaction. Policy grants authority.
Do not treat MCP, A2A, AG-UI, OpenLineage or AEO as interchangeable. Each protocol has a bounded role and must carry identity, audience, purpose, resource and delegation evidence into the governed core.
Authenticate the user or workload, bind tokens to the intended resource, preserve issuer and audience, and prohibit token passthrough.
FoundationMCP exposes tools, resources and prompts to compatible clients. HTTP contracts remain the deterministic service boundary beneath adapters.
Internal-readyUse for agent discovery, tasks, artifacts, status and delegation—not as a replacement for tool authorization.
Controlled pilotStream state, events and interactive components to users. User confirmation remains a governance action, not a visual affordance alone.
Controlled pilotStandardize job, run, dataset and facet evidence. It is a provenance protocol, not an agent protocol.
Internal-readyCorrelate traces, decisions, events and async workflows across protocol boundaries without placing secrets in telemetry.
FoundationAgent-payment protocols are relevant only when the platform permits economic action. They do not replace merchant identity, entitlement or dispute controls.
WatchOptimize public metadata, canonical citations, tool descriptions and machine-readable content. Keep authorization and premium content behind the gateway.
PracticeValidate the incoming token for the governed resource, then acquire or broker a separate downstream credential with the minimum required scope.
Bring governance into the developer loop.
Developers should access knowledge, lineage and approved tools from the CLI and IDE without receiving broad cloud credentials or bypassing content rights. Use remote, identity-bound pathways and an allow-listed tool registry.
Kiro CLI
Use enterprise OAuth to connect remote MCP servers and invoke read-only knowledge, lineage and operational tools with user-attributed audit.
IDE assistants
Expose the same remote registry to Kiro and other approved MCP-capable IDE clients. Pin tool versions and environment scopes.
CI/CD and autonomous coding
Use workload identity, repository/environment scope, dry runs, branch protections, budget limits and explicit production approvals.
| Developer pathway | Default actions | Identity | Controls |
|---|---|---|---|
| Knowledge MCP | Search, retrieve, cite, summarize | Interactive enterprise OAuth | Rights filters, per-resource authorization, no shared response cache |
| Lineage MCP | Resolve assets, trace, compare history, quality signals | Interactive enterprise OAuth | Asset authorization, environment scope, confidence and completeness |
| Operations MCP | Read logs, metrics, deployments and runbooks | OAuth or workload identity | Redaction, time range, account/environment and query budgets |
| Change tools | Create ticket, open PR, nonprod action | Step-up or workload identity | Confirmation, idempotency, rollback, repository and environment policy |
| Production tools | Remediation, publish, mutate or deploy | Step-up plus approval | G3 controls, human review, break-glass and post-condition validation |
Use Kiro CLI for the current CLI surface. “Q CLI” may still appear in older documentation and transition material.
The assistant is a client—not the entitlement authority.
External assistants may initiate discovery and authenticated retrieval, but the content owner retains identity, subscription, rights, geography, rate limits, revocation, billing and audit.
Public catalog
Expose approved titles, abstracts, product metadata and canonical links without premium body content.
Authenticated premium retrieval
OAuth-protected MCP or HTTPS checks the merchant account on every request and applies content, time, person and geo rights.
Checkout and commerce
Use merchant-hosted checkout first. Payment or irreversible actions require a separate G5 pathway and explicit confirmation.
| Control | Required posture before public exposure |
|---|---|
| OAuth and MCP | OAuth 2.1, PKCE, protected-resource metadata, exact redirect URIs, issuer/audience validation, short token lifetimes and no token passthrough |
| Entitlement | Merchant-owned account and subscription check on each premium request; no trust in assistant claims |
| Content rights | Resource authorization, excerpt and transformation limits, geography, embargo and revocation |
| Privacy | Minimum fields, explicit disclosure, retention limits, deletion workflows and regional processing review |
| Abuse | Per-user and per-client quotas, scraping detection, anomaly controls, credential revocation and incident response |
| Product operations | Public documentation, support, status, versioning, deprecation and assistant-platform review requirements |
External assistant publication, digital-goods monetization and platform policies continue to evolve. Treat premium content through public assistants as a gated product program with current-policy revalidation.
Route capabilities, not providers.
Clients request governed capabilities. The pathway manifest resolves model, tool, peer agent, region, quota, guardrail, timeout and fallback constraints.
Client-facing aliases
knowledge-balanced, regulated-text, low-latency, approved-image.
Aliases remain stable when providers, versions or regions change.
Provider adapter ownership
Credential handling, request translation, streaming normalization, retries, usage extraction and provider error mapping.
Authorization remains outside the adapter.
export type AICapability =
| "chat"
| "structured-output"
| "embeddings"
| "image-generation"
| "tool-use";
export interface ModelProviderAdapter {
readonly providerId: string;
supports(capability: AICapability): boolean;
invoke(
request: GovernedAIRequest,
context: GovernedContext,
signal: AbortSignal
): AsyncIterable<GatewayEvent>;
}
A provider outage may trigger an approved route change. It must not remove a required guardrail, broaden data residency or reduce the authorization posture.
Guard the whole context path.
Input guardrails alone are insufficient. Retrieved documents, structured tool arguments, generated URLs, image prompts and final output each require separate enforcement.
Before retrieval
- Schema and payload limits
- Unicode normalization
- Secret and PII detection
- Direct prompt-injection analysis
- Denied topics and abuse controls
Before inference
- Authorized context only
- Instruction/data separation
- Active markup removal
- Indirect prompt-injection analysis
- Protected prompt template
Before release
- Output guardrail
- Structured schema validation
- URL and HTML sanitization
- Citation authorization check
- Rights-based excerpt enforcement
| Layer | Primary controls | Failure posture |
|---|---|---|
| Edge | WAF, bot controls, coarse quotas, size limits | Reject obvious abuse early |
| Identity | JWT claims, issuer, audience, session assurance | Deny unverified identity |
| Request | JSON schema, normalization, replay and idempotency | Reject malformed request |
| Retrieval | Ingestion quarantine, metadata filters, resource authorization | Exclude unauthorized context |
| Model | Approved alias, token limits, region policy, timeout | No uncontrolled fallback |
| Output | Guardrail, data loss prevention, citation and format checks | Block, transform or safe refusal |
| Evidence | Redaction, digests, immutable audit archive | Do not log raw sensitive content by default |
A knowledge document can contain instructions designed to override the system, exfiltrate data or trigger tools. It must never inherit authority from its storage location.
Every answer needs an evidence trail.
The system must reconstruct who requested what, which rights and policies applied, what content was authorized, which route ran and what safety decisions occurred.
Operational telemetry
CloudWatch metrics and logs, X-Ray traces, latency, errors, quotas, provider health and cost units.
Governance evidence
Structured events through Data Firehose into a dedicated, KMS-encrypted S3 archive protected by Object Lock.
| Evidence category | Record | Avoid by default |
|---|---|---|
| Identity | Principal hash, tenant, application, session assurance | Email or unnecessary profile data |
| Authorization | Decision, policy store, bundle hash, determining policies | Opaque “allowed=true” only |
| Content | Requested, allowed and denied content IDs; rights versions | Full protected document text |
| AI route | Provider, alias, resolved model, prompt and guardrail versions | Unversioned “latest” references |
| Usage | Input/output tokens, latency, cost units, result class | Secrets, access tokens and raw credentials |
| Integrity | Input/output digests and archive checks | Raw prompt/response retention as the standard path |
Authorization evaluations
Zero cross-tenant, premium, person, embargo, time-window or geography leakage.
Safety evaluations
Direct and indirect injection, secret extraction, PII, jailbreaks, malicious URLs and tool misuse.
Quality evaluations
Groundedness, citation precision, retrieval recall, refusal correctness, answer relevance and hallucination rate.
A safer model cannot compensate for an authorization regression or a metadata-filter bug. Release gates must cover the entire trust path.
Enrich at the edge. Decide at the origin.
Edge infrastructure can reduce abuse and attach signed geography or network risk. It should not become the sole authority for legal or rights-sensitive access.
Akamai
Best when the enterprise perimeter already uses Akamai. EdgeWorkers can validate JWTs, apply bot signals and sign context.
CloudFront
AWS-native path with WAF, Shield, origin controls and viewer geography headers. Keep personalized AI responses uncacheable.
Varnish
Flexible and capable when already standardized. Requires explicit ownership for patching, policy distribution, observability and availability.
{
"requestId": "0190…",
"country": "CO",
"region": "ANT",
"networkRisk": "low",
"issuedAt": 1784451600,
"expiresAt": 1784451660,
"keyId": "edge-context-2026-07"
}
The gateway must strip internal headers, verify the edge signature and fail closed when a jurisdiction is required but cannot be established.
Trust scales through account boundaries.
Separate policy ownership, runtime operation, content stewardship, security detection and immutable evidence while keeping the synchronous request path regional and resilient.
Governance owns
Policy source, schemas, release authority, evaluation datasets and signed release manifests.
Platform owns
Runtime, regional policy stores, adapters, SLOs, incident response and deployment automation.
Content owners own
Authoritative rights metadata, classification, legal restrictions, embargoes and allowed AI transformations.
Start with governed knowledge.
Knowledge answering exercises the full platform boundary: identity, subscription, geography, resource rights, retrieval safety, model routing, citations and evidence.
| Capability | Recommended first implementation | Why |
|---|---|---|
| Perimeter | Akamai or CloudFront + AWS WAF | Existing enterprise edge or AWS-native control |
| API | API Gateway REST API | Managed ingress, authorizers, quotas and response streaming path |
| Runtime | TypeScript Lambda | Fast delivery and AWS SDK integration |
| Authorization | Amazon Verified Permissions | Externalized Cedar policy |
| Configuration | AWS AppConfig | Validated, staged operational policy and rollback |
| Knowledge | S3 + Bedrock Knowledge Bases | Managed retrieval with metadata filters |
| Rights | DynamoDB or dedicated rights service | Authoritative resource metadata and versioning |
| Safety | Bedrock Guardrails + application validators | Independent input/output checks and deterministic schema controls |
| Evidence | Firehose → S3 Object Lock | Durable and tamper-resistant governance trail |
Resolve tenant, durable subject, premium tier, groups and session assurance.
Include purpose, application, subscription, geography and requested collection scope.
Block or transform unsafe, secret-bearing or malformed inputs before retrieval.
Constrain by tenant, entitlement, validity window, country and allowed purpose.
Exclude any chunk whose authoritative rights record does not independently allow access.
Invoke the approved route, apply output guardrails and validate citations against the authorized source set.
Generated media stays quarantined until cleared.
Image generation adds person, brand, intellectual-property, publication and provenance controls. It should reuse the same action, policy and audit model.
Rights
Commercial use, publication, person likeness, protected brands, characters and permitted transformations.
Safety
Prompt controls, image moderation, minor safety, prohibited content and human review thresholds.
Provenance
Provider/model alias, prompt digest, watermark or C2PA status, output digest, retention and release decision.
Model availability, capability and regional support change. Keep provider identifiers behind the approved model catalog and evaluation process.
Choose operations proportionate to the workload.
Lambda is the preferred first runtime. ECS or EKS becomes appropriate when sustained connections, long workflows, specialized networking or self-hosted inference justify the operational cost.
| Runtime | Use when | Trade-off |
|---|---|---|
| Lambda | Initial gateway, bursty traffic, straightforward RAG, policy orchestration | Concurrency, long workflows, connection behavior and cold-path tuning |
| ECS/Fargate | Sustained traffic, connection pooling, long-lived streams, predictable capacity | More runtime operations and capacity management |
| EKS/Kubernetes | Existing platform mandate, service mesh, GPU/self-hosted inference, specialized sidecars | Highest security and operational burden |
TypeScript first
Best delivery velocity for Lambda, JSON contracts, AWS SDKs, streaming web APIs and shared application types.
Go selectively
Use for profiled high-throughput processors, sustained services, ingestion workers or resource-constrained components.
Stabilize the policy contract, adapter boundary and audit schema before creating a second runtime implementation.
Make the trust boundary explicit in code.
The initial repository should keep transport, domain policy, provider adapters, retrieval, safety and evidence isolated behind testable interfaces.
{
"id": "internal-lineage-triage",
"version": "2026-07-21.1",
"owner": "core-ai-platform",
"exposure": "internal",
"riskTier": "G1",
"identity": { "mode": "enterprise-oauth", "assurance": "standard" },
"clients": ["kiro-cli", "approved-ides", "internal-agents"],
"protocols": ["mcp", "https", "openlineage"],
"actions": ["lineage.resolve_asset", "lineage.trace", "lineage.compare"],
"resourceScopes": ["data-products:*:read"],
"domainPolicyBundle": "lineage-rights@42",
"toolPolicyBundle": "lineage-tools@18",
"retrievalRoute": "lineage-evidence-graph@7",
"modelAliases": ["regulated-analysis"],
"guardrailProfile": "internal-data@12",
"evaluationProfile": "lineage-triage@9",
"quotas": { "requestsPerMinute": 30, "maxTraversalNodes": 500 },
"audit": { "retentionClass": "security-7y", "rawContent": false },
"promotionStatus": "internal-ready"
}
It connects architecture, policy, deployment, client discovery, evaluation and audit. The runtime must reject unknown or unsigned manifest versions.
Data-plane API
POST /v1/responses
POST /v1/retrieve
POST /v1/images/generations
GET /v1/image-jobs/{jobId}
GET /v1/models
GET /v1/usage
Administrative boundary
Keep policy, model approval, guardrail, rights administration and evaluation APIs separate from the public AI data plane.
Require stronger identity assurance and explicit separation of duties.
src/
├── transport/
│ ├── api-gateway.ts
│ └── response-stream.ts
├── identity/
│ ├── jwt-validator.ts
│ └── principal-normalizer.ts
├── authorization/
│ ├── policy-client.ts
│ ├── action-catalog.ts
│ └── rights-authorizer.ts
├── safety/
│ ├── input-pipeline.ts
│ ├── output-pipeline.ts
│ └── guardrail-client.ts
├── retrieval/
│ ├── metadata-filter.ts
│ ├── knowledge-base.ts
│ └── citation-validator.ts
├── models/
│ ├── router.ts
│ ├── provider-adapter.ts
│ └── providers/bedrock.ts
├── audit/
│ ├── event-schema.ts
│ └── publisher.ts
└── application/
└── governed-response.ts
Non-negotiable decisions
Direct provider invocation by product applications is denied by IAM and organizational controls.
IAM secures workloads and AWS resources. Neither replaces the other.
Vector filters improve precision. They do not replace authorization.
No mutable “latest” dependency in a production decision trail.
Identity, jurisdiction, content rights and required safety state must be established.
Use IDs, digests, policy evidence and tightly governed diagnostic sampling.
Permission to answer does not imply permission to publish, send, modify or transact.
Safety, rights, provenance and release policy apply before delivery.
Promote pathways, not features.
Advance each capability through evidence-based readiness. Internal read-only pathways establish the platform contract before reversible actions, delegation, public assistants and commerce.
Foundation
Shared identity, pathway manifests, domain/tool policy compilation, audit schema and internal knowledge retrieval.
Lineage intelligence
Read-only asset resolution, historical traversal, quality evidence and cited triage in CLI and IDE clients.
Controlled agency
Reversible tools, AgentCore policy, confirmation, rollback, A2A delegation limits and sandboxed pilots.
External access
Public catalog, OAuth-protected premium retrieval, privacy/licensing review, public abuse controls and support.
Economic actions
Merchant-owned checkout, non-repudiation, disputes, regulatory controls and explicit human confirmation.
Identity issues the ticket. Policy controls the gate. Rights determine the destination. Guardrails inspect the cargo. Evidence records the journey. Operating model
Pin stable contracts. Isolate evolving surfaces.
Several managed services, protocols and assistant-publication programs are changing rapidly. Keep them behind adapters and release gates so evolution does not weaken authorization or lock the platform to preview behavior.
AgentCore Agent Registry
Preview status and the announced namespace migration require revalidation before making registry identifiers a durable production contract.
MCP evolution
Pin the stable 2025-11-25 authorization contract and run conformance tests. Treat enterprise-managed authorization proposals and roadmap items as future extensions.
Managed GraphRAG constraints
Track source limits, graph lifecycle, graph-construction model changes, cross-region behavior and Neptune Analytics operating characteristics.
Structured retrieval residency
Redshift structured knowledge bases may use cross-region inference. Data residency and regional processing must be part of pathway admission.
External assistant monetization
OAuth connectivity can be engineered now, but public app approval and digital-goods monetization rules require current OpenAI policy review.
Model and image lifecycle
Never hard-code provider model identifiers. Use aliases, lifecycle monitoring, replacement evaluations and release manifests.
Research and source register.
The architecture prioritizes official AWS, protocol-owner and OpenAI documentation, with NIST and OWASP for governance and threat coverage. Service limits, preview status and external platform policies must be revalidated at implementation time.
Method
Synthesized service capabilities, security boundaries, policy design, evaluation practices and deployment trade-offs into an engineering reference architecture.
Evidence preference
Official AWS service documentation first. NIST and OWASP for risk and threat taxonomy. Edge-vendor documentation for edge-specific capabilities.
Freshness rule
Reconfirm model availability, regions, quotas, pricing, API limits and service-specific feature support before production approval.
| ID | Source | Supports |
|---|---|---|
| S01 | Amazon Verified Permissions overview | Externalized fine-grained authorization with Cedar |
| S02 | Verified Permissions schemas | Strict schemas and policy validation |
| S03 | AgentCore Policy | Deterministic policy enforcement for AgentCore Gateway traffic |
| S04 | AgentCore Cedar policies | Cedar principals, tools and parameter-aware authorization |
| S05 | AgentCore Policy authorization flow | OAuth claims, tool input and policy decision flow |
| S06 | AWS AppConfig deployment monitoring | Alarm-driven rollback and staged configuration deployment |
| S07 | Bedrock ApplyGuardrail API | Independent input and output guardrail evaluation |
| S08 | Amazon Bedrock Knowledge Bases | Managed retrieval-augmented generation |
| S09 | Create a Bedrock Knowledge Base | Current managed stores and creation options |
| S10 | Kendra GenAI index for Bedrock Knowledge Bases | Kendra enterprise search integration |
| S11 | Structured data knowledge bases | Managed structured retrieval using Redshift |
| S12 | GenerateQuery API | Natural-language query generation for structured data |
| S13 | Amazon S3 Vectors with Bedrock Knowledge Bases | S3-native vector storage and metadata constraints |
| S14 | AWS vector database comparison for RAG | Vector store selection trade-offs |
| S15 | Choosing an AWS RAG option | Decision guidance across managed and custom RAG |
| S16 | Bedrock GraphRAG with Neptune Analytics | Managed semantic graph construction and limitations |
| S17 | GraphRAG metadata filtering best practices | Filter design and query performance |
| S18 | Amazon Neptune Analytics | In-memory graph analytics characteristics |
| S19 | Bedrock RAG evaluations | Retrieve-only and retrieve-and-generate evaluation |
| S20 | Data lineage in SageMaker Unified Studio | OpenLineage-compatible lineage and historical views |
| S21 | Amazon DataZone PostLineageEvent | OpenLineage event ingestion |
| S22 | Amazon DataZone GetLineageNode | Programmatic lineage node retrieval |
| S23 | AWS Glue lineage in Unified Studio | Automatic lineage capture for supported jobs |
| S24 | SageMaker Unified Studio permissions | Catalog access-control considerations |
| S25 | AWS Glue Data Quality | Data-quality rules, scores and history |
| S26 | OpenLineage specification | Jobs, runs, datasets and extensible facets |
| S27 | Amazon Bedrock AgentCore Gateway | Managed gateway for tools, APIs and MCP targets |
| S28 | AgentCore Runtime A2A support | A2A and other runtime protocol patterns |
| S29 | Amazon Bedrock AgentCore Identity | Agent, user and downstream credential management |
| S30 | MCP authorization specification 2025-11-25 | OAuth 2.1, resource metadata, PKCE and token audience |
| S31 | MCP roadmap | Protocol evolution and future work |
| S32 | AG-UI introduction | Open event protocol for agent-to-user interfaces |
| S33 | Kiro CLI documentation | Current AWS developer CLI surface |
| S34 | MCP with Amazon Q Developer and Kiro | MCP server configuration and remote access |
| S35 | OpenAI Apps SDK authentication | OAuth-protected MCP servers for ChatGPT apps |
| S36 | Connect an MCP server from ChatGPT | ChatGPT connection and testing flow |
| S37 | Submit apps to ChatGPT | App review, publication and policy process |
| S38 | NIST AI Risk Management Framework | AI governance and risk lifecycle |
| S39 | OWASP Top 10 for LLM Applications | Prompt injection, excessive agency and related threats |
| S40 | AWS Well-Architected Agentic AI Lens | Agent boundaries, autonomy and human oversight |
| S41 | AWS Generative AI Security Reference Architecture | Security scoping matrices and control patterns |
| S42 | AWS tool integration security guidance | Tool authorization, prompt injection and privilege escalation |
| S43 | Amazon S3 Object Lock | WORM protection for governance evidence |
| S44 | CloudTrail log integrity validation | Cryptographic digest validation |
| S45 | Amazon Bedrock evaluations | Model and RAG evaluation programs |
| S46 | Lambda functions with TypeScript | TypeScript Lambda implementation |
| S47 | Lambda response streaming | Streaming response support |
| S48 | CloudFront geographic restrictions | Edge geolocation behavior and limitations |
| S49 | Akamai EdgeWorkers JWT | Edge JWT verification |
| S50 | Amazon Titan Image Generator | Image generation, watermark and C2PA features |
| S51 | AgentCore Agent Registry | Preview registry behavior and lifecycle watch item |
| S52 | Direct ingestion into Bedrock Knowledge Bases | Event-driven document ingestion |
| S53 | Bedrock Knowledge Base data-source connectors | S3, Confluence, SharePoint, Salesforce and other sources |
| S54 | Bedrock Converse API | Provider-consistent conversational inference interface |
Each major section declares source IDs in its header. The source registry maps those IDs to authoritative documentation and the specific architectural claim they support.