@aws/nx-plugin-mcp 1.0.0-rc.40 → 1.0.0-rc.42

package/docs/guides/py-agent.mdx

@@ -583,6 +583,50 @@ To invoke your AG-UI agent from a React website, use the <Link path="/guides/con
 Refer to the <Link path="/guides/connection/react-agui">`connection` generator guide</Link> for details about how the connection is set up.
 </OptionFilter>
 
+## Securing your Agent
+
+<Snippet name="agent/securing-your-agent" parentHeading="Securing your Agent" />
+
+<Tabs syncKey="agent-framework">
+<TabItem label="Strands" _filter={{ framework: 'strands' }}>
+```python
+# agent.py
+import os
+
+from strands import Agent
+from strands.models import BedrockModel
+
+model = BedrockModel(
+    model_id=os.environ.get("MODEL_ID"),
+    guardrail_id=os.environ["GUARDRAIL_ID"],
+    guardrail_version=os.environ.get("GUARDRAIL_VERSION", "DRAFT"),
+)
+
+agent = Agent(model=model)
+```
+
+See the Strands [Guardrails](https://strandsagents.com/docs/user-guide/safety-security/guardrails/) guide for more detail.
+</TabItem>
+<TabItem label="LangChain" _filter={{ framework: 'langchain' }}>
+```python
+# agent.py
+import os
+
+from langchain_aws import ChatBedrockConverse
+
+model = ChatBedrockConverse(
+    model=os.environ.get("MODEL_ID"),
+    guardrail_config={
+        "guardrailIdentifier": os.environ["GUARDRAIL_ID"],
+        "guardrailVersion": os.environ.get("GUARDRAIL_VERSION", "DRAFT"),
+    },
+)
+```
+
+See the [`ChatBedrockConverse`](https://docs.langchain.com/oss/python/integrations/chat/bedrock_converse) documentation for the `guardrail_config` fields.
+</TabItem>
+</Tabs>
+
 ## Connections
 
 Use the <Link path="guides/connection">`connection`</Link> generator to integrate this project with others in your workspace. The following connections involve this project:

package/docs/guides/react-website.mdx

@@ -136,6 +136,49 @@ A default `Content-Security-Policy` is enforced. It restricts scripts and framin
 
 `runtime-config.json` is served with `Cache-Control: no-cache` so that browsers always fetch the latest configuration after a redeploy, rather than using a stale cached copy.
 
+#### Custom Domain & TLS
+
+By default the distribution uses the default CloudFront domain name (`*.cloudfront.net`) and its default certificate, which does not support enforcing a minimum TLS version of 1.2. To serve your website from your own domain, supply an [ACM certificate](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) (which must reside in `us-east-1` for use with CloudFront) and your domain names — a minimum TLS version of 1.2 is then enforced for viewers:
+
+<Infrastructure>
+<Fragment slot="cdk">
+Pass the `certificate` and `domainNames` props through in your generated website construct in `packages/common/constructs/src/app/static-websites`:
+
+```ts {6-9}
+export class MyWebsite extends StaticWebsite {
+  constructor(scope: Construct, id: string) {
+    super(scope, id, {
+      websiteName: 'MyWebsite',
+      websiteFilePath: ...,
+      domainNames: ['www.example.com'],
+      certificate: Certificate.fromCertificateArn(scope, 'Cert',
+        'arn:aws:acm:us-east-1:123456789012:certificate/...'),
+    });
+  }
+}
+```
+</Fragment>
+<Fragment slot="terraform">
+Set the `custom_domain_names` and `acm_certificate_arn` variables in your generated website module in `packages/common/terraform/src/app/static-websites`:
+
+```hcl {5-6}
+module "static_website" {
+  source            = "../../../core/static-website"
+  website_name      = "my-website"
+  website_file_path = ...
+  custom_domain_names = ["www.example.com"]
+  acm_certificate_arn = "arn:aws:acm:us-east-1:123456789012:certificate/..."
+
+  providers = {
+    aws.us_east_1 = aws.us_east_1
+  }
+}
+```
+</Fragment>
+</Infrastructure>
+
+You will also need to create DNS records (for example in Route 53) pointing your domain at the CloudFront distribution.
+
 ## Implementing your React Website
 
 The [React documentation](https://react.dev/learn) is a good place to start to learn the basics of building with React.

package/docs/guides/security.mdx

@@ -0,0 +1,75 @@
+---
+title: Security
+description: Security features included in projects generated by the Nx Plugin for AWS
+---
+
+import Link from '@components/link.astro';
+
+:::caution[Reporting Security Issues]
+To report a potential security issue in the Nx Plugin for AWS itself, please refer to [SECURITY.md](https://github.com/awslabs/nx-plugin-for-aws/blob/main/SECURITY.md) — do not create a public GitHub issue.
+:::
+
+## Security Controls
+
+Projects scaffolded by the Nx Plugin for AWS include a number of security controls out of the box. This page provides an overview of those controls and links to the relevant guides for more detail.
+
+### Infrastructure Scanning
+
+Infrastructure projects are configured with [Checkov](https://www.checkov.io/) as part of the `build` target, so insecure infrastructure configuration fails the build:
+
+- CDK projects synthesize CloudFormation templates which are scanned by Checkov. See <Link path="/guides/typescript-infrastructure#security-testing">Security Testing</Link> for details.
+- Terraform projects run Checkov directly against your Terraform code. See <Link path="/guides/terraform-project">Terraform Projects</Link>.
+
+Where vended infrastructure suppresses a Checkov rule, the suppression is scoped to the specific resource and annotated with a justification. The shared `suppressRules` helper requires a reason for every suppression, and we recommend following the same practice in your own code. See <Link path="/guides/typescript-infrastructure#suppressing-checkov-checks">Suppressing Checkov Checks</Link>.
+
+### Container Image Scanning
+
+Projects which build container images (for example agents, MCP servers, and database migration images) include a `trivy` target which scans images for HIGH and CRITICAL vulnerabilities before they are deployed, failing the build on findings. See <Link path="/guides/docker-bundling">Docker Bundling</Link> for details, including how to suppress findings with a `.trivyignore` file.
+
+### Credential Scanning
+
+Workspaces include [git-secrets](https://github.com/awslabs/git-secrets) pre-commit hooks which scan staged files for AWS credential patterns, preventing accidental commits of access keys and other sensitive values. See the <Link path="/guides/workspace#git-secrets">Git Secrets</Link> section of the workspace guide.
+
+### Authentication
+
+APIs, agents, and MCP servers use AWS IAM (SigV4) authentication by default:
+
+- <Link path="/guides/trpc">tRPC</Link>, <Link path="/guides/fastapi">FastAPI</Link>, and <Link path="/guides/ts-smithy-api">Smithy</Link> APIs default to IAM authentication, with Cognito and custom authorizers available as options. The vended custom authorizer stub denies requests by default.
+- <Link path="/guides/ts-agent">Agents</Link> and <Link path="/guides/ts-mcp-server">MCP servers</Link> deployed to Amazon Bedrock AgentCore Runtime use IAM (SigV4) authentication by default, with JWT-based Cognito authentication as an option.
+- The <Link path="/guides/react-website-auth">website auth generator</Link> vends an Amazon Cognito user pool with multi-factor authentication (MFA) required, a strong password policy, and deletion protection enabled.
+
+### Encryption
+
+Vended infrastructure encrypts data in transit and at rest:
+
+- Websites are served via CloudFront with HTTP redirected to HTTPS, and a response headers policy including HTTP Strict Transport Security (HSTS), a Content Security Policy, and other <Link path="/guides/react-website#security-headers">security headers</Link>. A WAF with AWS managed rules is associated with the distribution.
+- S3 buckets block all public access, enforce SSL-only access via bucket policies, are encrypted (KMS with key rotation for website content), and deliver server access logs to CloudWatch log groups encrypted with customer-managed KMS keys, where they can be queried with Logs Insights and alarmed on.
+- API access logs are written to CloudWatch log groups encrypted with customer-managed KMS keys with rotation enabled.
+- <Link path="/guides/ts-rdb">Aurora databases</Link> enable storage encryption with a customer-managed KMS key, generate credentials in AWS Secrets Manager (never hardcoded), and support automatic credential rotation.
+
+### Least Privilege
+
+Vended CDK constructs and Terraform modules follow least privilege:
+
+- Constructs expose `grant*` methods (for example `grantInvokeAccess` on APIs and agents, `grantConnect` on databases) so consumers grant only the access they need.
+- IAM policies in vended infrastructure are scoped to specific resources and actions. Where a wildcard resource is required by the AWS service (for example `ecr:GetAuthorizationToken`), it is limited to those actions and scoped with conditions where supported.
+
+### Dependency Licensing
+
+The <Link path="/guides/license">license generator</Link> configures automated license header management and dependency license checking against an allowlist of approved licenses, helping you catch problematic transitive dependencies before they ship.
+
+## Responsibility
+
+Security and compliance is a shared responsibility. AWS describes this through the [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/), which distinguishes between security *of* the cloud (the responsibility of AWS) and security *in* the cloud (your responsibility as the customer).
+
+The Nx Plugin for AWS helps you address parts of your side of that model. Its generators vend secure foundations and encode AWS best practices within the scope of the code they produce — the controls described above. This reduces the effort required to build securely, but it does not transfer ownership of security to the plugin.
+
+**You own the code that is generated into your workspace and remain responsible for its security.** Once vended, generated code is yours to modify, extend, and operate, and it must be treated the same as any other code you author.
+
+In particular:
+
+- **The scope of the plugin is limited to its generators.** The plugin has no knowledge of your application's business logic, data classification, threat model, or regulatory obligations, and cannot make decisions that depend on them.
+- **Authentication is configured, but authorization is not.** APIs are protected with authentication by default (for example IAM/SigV4), but the plugin cannot determine *which* authenticated principals should be permitted to perform *which* operations on *which* resources. Fine-grained authorization depends on your business logic and must be designed, implemented, and tested by you.
+- **Generated code is a starting point, not a finished product.** As you add functionality, you introduce security considerations the plugin cannot anticipate — input validation, data handling, secrets management, dependency choices, and integrations with other systems.
+
+Accordingly, you should review generated code and the applications you build on top of it in line with your own organisation's security policies, standards, and review processes, and subject them to the same threat modelling, security testing, and approval gates you apply to any production workload. The controls vended by the plugin are intended to complement those processes, not to replace them.

package/docs/guides/ts-agent.mdx

@@ -483,6 +483,28 @@ To invoke your AG-UI agent from a React website, use the <Link path="/guides/con
 Refer to the <Link path="/guides/connection/react-agui">`connection` generator guide</Link> for details about how the connection is set up.
 </OptionFilter>
 
+## Securing your Agent
+
+<Snippet name="agent/securing-your-agent" parentHeading="Securing your Agent" />
+
+```typescript
+// agent.ts
+import { Agent } from '@strands-agents/sdk';
+import { BedrockModel } from '@strands-agents/sdk/models/bedrock';
+
+const model = new BedrockModel({
+  modelId: process.env.MODEL_ID,
+  guardrailConfig: {
+    guardrailIdentifier: process.env.GUARDRAIL_ID!,
+    guardrailVersion: process.env.GUARDRAIL_VERSION ?? 'DRAFT',
+  },
+});
+
+const agent = new Agent({ model, /* ... */ });
+```
+
+See the Strands [Guardrails](https://strandsagents.com/docs/user-guide/safety-security/guardrails/) guide for more detail.
+
 ## Connections
 
 Use the <Link path="guides/connection">`connection`</Link> generator to integrate this project with others in your workspace. The following connections involve this project:

package/docs/snippets/agent/securing-your-agent.mdx

@@ -0,0 +1,39 @@
+---
+title: Securing your Agent
+---
+
+Agents act on untrusted input and can drive real actions through their tools, so it's worth considering security from the start. The following practices apply to the generated agent.
+
+### Treat model input and output as untrusted
+
+Prompts can contain adversarial instructions (prompt injection), and model output is non-deterministic — neither should be trusted in security-sensitive logic:
+
+- Define strict input schemas for your tools, as in the generated example tool. Constrain values to what the tool actually needs (enums, length limits, numeric ranges) rather than accepting free-form strings.
+- Never pass model output directly into shell commands, SQL queries, code evaluation, or rendered HTML without validation or encoding.
+- Apply authorization checks in your tools and downstream services — don't rely on the system prompt to prevent the model from misusing a tool it has access to.
+
+Strands' [Prompt Engineering](https://strandsagents.com/docs/user-guide/safety-security/prompt-engineering/) and [Responsible AI](https://strandsagents.com/docs/user-guide/safety-security/responsible-ai/) guides cover writing robust, safety-conscious system prompts.
+
+### Scope tool permissions tightly
+
+Grant the agent's IAM role only the permissions its tools need. The vended CDK constructs and Terraform modules expose `grant*` methods and scoped policies for this purpose — for example granting an agent access to invoke a specific API rather than attaching broad managed policies. Where a tool acts on behalf of a user, prefer authorizing the action using the calling user's identity (passed through via the request context) over the agent's own ambient permissions.
+
+### Provide a kill switch
+
+Because model behaviour can change in unexpected ways, plan for quickly disabling or swapping the model without a code change:
+
+- Read the model ID from configuration (for example a `MODEL_ID` environment variable) so operators can switch or roll back to a different model by updating configuration.
+- Gate the agent behind a feature flag so its AI functionality can be disabled entirely. When disabled, return a generic message rather than an error, and ensure the rest of your application degrades gracefully.
+
+Document how to flip these controls in your operational runbook.
+
+### Protect sensitive data
+
+- Avoid logging prompts and completions, which may contain user data. The generated agent's model error logging hook logs error metadata only, not conversation content — keep this property when adding your own logging.
+- Return generic error messages to users; log detailed errors server-side.
+- Isolate conversation state between users and sessions, and authorize access to any persisted session data.
+- Redact personally identifiable information (PII) from prompts and outputs — either with a Bedrock Guardrail sensitive information filter (below) or, for Strands agents, the approaches in the [PII Redaction](https://strandsagents.com/docs/user-guide/safety-security/pii-redaction/) guide.
+
+### Amazon Bedrock Guardrails
+
+[Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) provide configurable content filters, denied topics, and sensitive information (PII) filters which are evaluated on model input and output. You can attach a guardrail to the model used by the generated agent:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws/nx-plugin-mcp",
-  "version": "1.0.0-rc.40",
+  "version": "1.0.0-rc.42",
   "repository": {
     "type": "git",
     "url": "https://github.com/awslabs/nx-plugin-for-aws.git",