🧠 Security Engineer Agent Specification¶

🎯 Agent Purpose¶

The Security Engineer Agent enforces runtime security across the generated software stack by transforming security architecture into concrete, enforceable, and deployable outputs.

Operating under the strategic guidance of the Security Architect Agent, it:

Implements RBAC, token scopes, secret mounts, security contexts, and mTLS
Injects API-level security policies (OAuth2 scopes, rate-limiting, threat tagging)
Validates security annotations in generated artifacts
Emits audit and trace events for security observability

It ensures every service, API, or job is secure by default, with no manual post-processing required.

🛠️ Responsibilities¶

Area	Responsibility
Infrastructure	Apply RBAC, PodSecurity, service accounts, `securityContext`
Application Layer	Inject token scopes, access guards, tenant isolation
API Gateway	Assign OAuth scopes, rate limits, identity verification layers
Secret Management	Mount Vault/KeyVault secrets securely
Traceability	Ensure all artifacts include `trace_id`, `security_policy_id`
Compliance	Validate against tenant and environment-specific hardening profiles

🔗 Execution Flow Integration Diagram¶

flowchart TD

  subgraph Design
    A[Security Architect Agent]
  end

  subgraph Engineering
    B[Microservice Generator Agent]
    C[Infrastructure Engineer Agent]
    D[Pull Request Creator Agent]
  end

  subgraph Enforcement
    E[Security Engineer Agent]
  end

  subgraph Deployment
    F[DevOps Agent]
    G[CI/CD Pipelines]
  end

  A --> E
  B --> E
  E --> C
  E --> D
  E --> F
  F --> G

Hold "Alt" / "Option" to enable pan & zoom

🔎 Explanation:

The Security Architect Agent defines the security model, policies, and templates.
The Security Engineer Agent receives runtime inputs from generated components (B), applies and enforces policies, and forwards compliant artifacts to deployment and pull request layers.

🧩 Role Within the Factory Lifecycle¶

Lifecycle Phase	Security Engineer Agent Role
🔍 Trace Design	Implements blueprint-linked policies and RBAC
🏗️ Service Assembly	Enforces secure defaults for each component
🔐 Hardened Infrastructure	Injects pod-level security, mTLS, service identities
📦 Delivery	Tags security metadata for audit trail
🚨 Observability	Emits `SecurityImplemented` or `SecurityViolationDetected` events

🔖 Example Outcome¶

When a microservice is generated with HTTP handlers and an Azure Key Vault secret requirement, the Security Engineer Agent will:

Inject token validation guards

Mount secrets securely with correct volumes

Attach RBAC roles to the deployment

Emit SecurityImplemented event with trace and policy linkage

✅ Summary¶

The Security Engineer Agent ensures every component in the ConnectSoft software factory is:

🛡️ Secure-by-default
🔍 Trace-linked to security policies
🧩 Composable with other agent outputs
📦 Ready for deployment with no manual hardening

It is the execution-layer guardian of Zero Trust, embedded deeply into the agentic production line of the AI Software Factory.

🧰 Core Responsibilities¶

The Security Engineer Agent transforms security blueprints and architecture constraints into actionable runtime enforcement across:

Kubernetes manifests
Application service layers
API gateways
Secret management systems
Token validation and RBAC layers

It ensures every generated component is compliant, auditable, and hardened by default — without requiring manual developer or DevOps intervention.

🔐 Execution-Level Deliverables¶

✅ 1. RBAC Role and Binding Injection¶

Create Role and RoleBinding resources scoped per service
Bind correct ServiceAccount to deployment
Align with scope and tenant namespace

Example: orderservice may be granted queue-publisher and config-reader roles only.

✅ 2. Token Scope and OAuth Rule Mapping¶

Assign OAuth2 scopes to handlers or endpoints
Inject route-level claims and validations
Enforce aud, sub, role, or tenant as JWT claims

Supports Azure AD, OpenIddict, or ConnectSoft OAuth2 implementations.

✅ 3. Pod SecurityContext Enforcement¶

Enforce:
runAsNonRoot: true
allowPrivilegeEscalation: false
seccompProfile, capabilities, etc.
Match policies from security-profile.yaml

✅ 4. Secret Management¶

Resolve secrets from:
Azure Key Vault
Kubernetes Sealed Secrets
Mount as:
volumeMounts
envFrom
Token injection

Supports per-environment, per-tenant variants.

✅ 5. API Gateway Security Annotations¶

Inject:
OAuth scopes
Rate limits
IP allowlists / threat tags
Risk score labels (for runtime observability)

✅ 6. Audit Metadata Injection¶

Add:
security_policy_id
compliance_tag (e.g., hipaa, pci-dss)
agent_origin: security-engineer-agent
Annotate all affected resources and YAMLs

✅ 7. Event Emission¶

Emit:
SecurityImplemented
SecurityViolationDetected
Enables observability and CI/CD gatekeeping

📌 Summary Table of Deliverables¶

Responsibility	Output
RBAC Enforcement	`role.yaml`, `rolebinding.yaml`, `serviceaccount.yaml`
Pod Hardening	`securityContext` in `deployment.yaml`
Secrets	`volumeMount`, `env`, or vault injection config
API Guardrails	API-level metadata in gateway ingress annotations
Auditability	`metadata.annotations.security_policy_id`
Telemetry	`SecurityImplemented` event to Observability Agent

🧠 Summary¶

The Security Engineer Agent is a runtime security enforcer responsible for:

Injecting traceable security logic
Enforcing compliance on every artifact
Applying hardening patterns programmatically

It ensures zero human hardening debt across ConnectSoft’s AI-generated software stack.

📥 Inputs¶

The Security Engineer Agent consumes both static policy inputs from architecture and dynamic runtime inputs from the service generation pipeline. All inputs are trace-linked, environment-aware, and scoped to the specific service/component being hardened.

🔐 Primary Inputs¶

✅ 1. Trace Context¶

Provided by: Blueprint registry, Microservice Generator Agent, Infrastructure Engineer Agent

trace_id: trace-auth-914
blueprint_id: usecase-login-flow
component_scope: Identity
execution_id: exec-914-auth

✅ 2. Security Policy Definition¶

Provided by: Security Architect Agent

security_policy_id: sec-profile-identity-v1
enforce:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  restrictedCapabilities: [ALL]
  enable_mtls: true
  allowed_token_claims:
    - sub
    - tenant
    - role
  rbac:
    - publisher
    - config-reader

✅ 3. Component Metadata¶

Provided by: Microservice Generator Agent

component:
  name: AuthService
  transport: http
  image: ghcr.io/connectsoft/authservice:1.4.2
  env:
    - name: AUTH_SECRET
      valueFrom:
        secretRef: auth-vault-secret

✅ 4. Kubernetes Deployment Template (Pre-enforcement)¶

Provided by: Infrastructure Engineer Agent

metadata:
  name: authservice
  labels:
    trace_id: trace-auth-914
spec:
  containers:
    - name: main
      image: ghcr.io/connectsoft/authservice:1.4.2
      ports:
        - containerPort: 8080

The agent reads this and injects securityContext, identity bindings, etc.

✅ 5. Secrets Registry Mapping¶

Provided by: VaultResolverAgent or Infra Policy Agent

secrets:
  - name: auth-vault-secret
    type: azure-keyvault
    mountPath: /mnt/secrets/auth
    env: true

✅ 6. API Gateway Access Definitions¶

Provided by: API Security Architect Agent or derived from annotations

api_security:
  endpoints:
    - path: /login
      methods: [POST]
      oauth_scopes: [auth:write]
      rate_limit: 50rps

✅ 7. Environment Profile¶

Injected or resolved from orchestration

target_environment: staging
tenant: tenant-vetspire
features:
  otel_enabled: true
  secrets_mount_strategy: env

📂 Optional Inputs¶

Source	Use
Human override config	Temporary allow-list or exception
Prior RBAC history	Prevent duplicate roles for shared services
Security audit logs	Enable delta-based hardening patching

🧠 Input Integration Summary¶

Input Type	Source	Purpose
Trace + Component Context	Upstream engineering agents	Identify scope, origin, linkage
Security Policy	Architect Agent	Drive what should be enforced
Manifest (Pre-Hardening)	Infra Engineer Agent	Determine where and how to apply security
Secrets / Vault Map	Vault or resolver agent	Map external secrets to runtime
API Access	Gateway templates	Attach OAuth2 scopes and access limits

🧠 Summary¶

The Security Engineer Agent consumes a multi-source, trace-first input bundle that allows it to:

Determine what security policy to enforce
Understand the shape of the service and its transport/identity needs
Apply environment- and tenant-specific overrides
Emit hardened, audit-ready outputs with no ambiguity

📤 Outputs¶

The Security Engineer Agent emits a set of security-enforced infrastructure artifacts and policy outputs, along with traceable telemetry events for observability and compliance auditing.

Each output is scoped per service/component and environment, and is linked back to its originating blueprint and policy profile.

✅ 1. Hardened Kubernetes Resources¶

🧾 Updated `deployment.yaml`¶

Adds securityContext block:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

🧾 Adds `serviceaccount.yaml`¶

Includes pod identity + traceable labels:

metadata:
  name: authservice-sa
  labels:
    trace_id: trace-auth-914
    blueprint_id: usecase-login-flow

🧾 Adds `role.yaml` and `rolebinding.yaml`¶

Based on required scopes (e.g., config-reader, queue-publisher)

✅ 2. Secret Injection Configuration¶

Based on tenant + environment strategy:

volumes:
  - name: secret-volume
    projected:
      sources:
        - secret:
            name: auth-vault-secret

envFrom:
  - secretRef:
      name: auth-vault-secret

Or as inline env vars (if policy allows).

✅ 3. API Security Metadata Block¶

Injected into API gateway ingress or OpenAPI spec (if applicable):

x-security:
  oauth_scopes: [auth:read, auth:write]
  rate_limit: 100rps
  threat_tags: ["sensitive-entrypoint"]
  risk_score: 8.5

✅ 4. Annotations & Labels for Auditability¶

Every output must include:

metadata:
  annotations:
    security_policy_id: sec-profile-identity-v1
    agent_origin: security-engineer-agent
    execution_id: exec-914-auth
    blueprint_id: usecase-login-flow

✅ 5. Event: `SecurityImplemented`¶

Structured event emitted upon successful hardening:

{
  "event": "SecurityImplemented",
  "trace_id": "trace-auth-914",
  "component": "AuthService",
  "security_policy_id": "sec-profile-identity-v1",
  "artifacts": ["deployment.yaml", "serviceaccount.yaml", "role.yaml"],
  "agent": "security-engineer-agent",
  "timestamp": "2025-05-07T23:58:01Z"
}

Consumed by:

Observability Agent
DevOps Agent
Documentation Agent
Tech Lead Agent

❌ Event: `SecurityViolationDetected` (optional)¶

If the agent identifies a misaligned or missing security directive:

{
  "event": "SecurityViolationDetected",
  "reason": "missing securityContext in deployment",
  "trace_id": "trace-auth-914",
  "component": "AuthService",
  "severity": "critical"
}

📦 Optional Outputs¶

Output	Condition
Helm values patch	For security injection via Helm chart override
OPA policy module (Rego)	For environments with Gatekeeper / runtime policy engines
Signed artifact manifest	For attestation or SBOM purposes (future enhancement)

🧠 Summary¶

The Security Engineer Agent outputs are:

✅ Declarative and Kubernetes-native
✅ Traceable and auditable
✅ Hardened per environment, tenant, and component
✅ Immediately deployable and CI/CD-compatible

It ensures that security is not an afterthought — it's built into every artifact, every time.

📚 Knowledge Base¶

The Security Engineer Agent does not reinvent security logic during each execution. Instead, it relies on a structured, versioned knowledge base maintained by the Security Architect Agent, including:

Hardening profiles
Role-based access rules
Secret mount templates
mTLS and pod identity policies
Gateway security overlays
Reusable injection blocks

These assets ensure the agent operates with consistency, determinism, and trace alignment.

🧾 Categories of Knowledge¶

✅ 1. Security Profiles (Policy Blueprints)¶

ID	Description
`sec-profile-default`	Default hardened settings for microservices
`sec-profile-identity-v1`	Used for auth APIs — includes scopes, trust, and RBAC
`sec-profile-worker-light`	Minimal RBAC for background job consumers

Each profile includes:

runAsNonRoot: true
capabilities: [DROP_ALL]
tokenScopes: [auth:read, auth:write]
vaultMountStrategy: env

✅ 2. RBAC Role Templates¶

Role	Grants
`config-reader`	GET on configmap, secret (non-sensitive)
`queue-publisher`	POST to service bus / message queue
`db-reader-tenant-scoped`	SELECT from db views with tenant_id filter

Templated as YAML snippets or Helm values patches.

✅ 3. SecurityContext Injection Blocks¶

Reusable patches to inject into containers or deployments:

securityContext:
  runAsUser: 1000
  runAsNonRoot: true
  capabilities:
    drop: ["ALL"]
  allowPrivilegeEscalation: false
  seccompProfile:
    type: RuntimeDefault

✅ 4. Secrets Injection Patterns¶

Strategy	Output
`env`	`envFrom: secretRef`
`volumeMount`	`projected: sources: - secret:`
`vault-agent-sidecar`	Generates vault agent configmap and init container

✅ 5. OAuth2 Scope Annotations¶

For API Gateway, reverse proxies, or service metadata:

x-oauth-scopes:
  - auth:read
  - user:email
  - billing:write
x-risk-score: 9.3

Used by:

Pull Request Validator Agent
API Gateway Hardening
Rate Limit Enforcer

✅ 6. Security Labels & Trace Fields¶

Label	Purpose
`security_policy_id`	Injected into all manifests
`agent_origin`	Always set to `security-engineer-agent`
`compliance_tag`	e.g., `pci-dss`, `hipaa`, `soc2`
`risk_level`	optional enum: low, medium, high, critical

✅ 7. Helm Security Overlays (optional)¶

Customizable patch snippets to inject security into Helm charts:

podSecurityContext:
  fsGroup: 2000
containerSecurityContext:
  allowPrivilegeEscalation: false

📘 Storage and Access¶

Store	Use
Redis or Cosmos DB	Real-time policy lookup and overlay application
Blob / Git	Versioned security policy templates
Vector DB	Blueprint-to-policy similarity matching (future use)
SK Planner Memory	Temporary scratchpad for active plan context

🔒 Governance¶

Profiles are signed and versioned by the Security Architect Agent
All injection operations must trace back to an explicit security_policy_id
Policies can be overridden only with techlead-override: true

🧠 Summary¶

The Security Engineer Agent’s knowledge base ensures every output is:

🔒 Hardened consistently across environments
🔍 Traceable to an approved policy profile
🧩 Composable with Helm, Kubernetes, API layers
🚫 Incapable of security drift or undocumented mutation

It converts architectural intent into enforced, repeatable security execution — at scale, and by design.

🔄 Process Flow¶

flowchart TD
    A[Receive Inputs: Component + Security Policy] --> B[Load Policy Profile]
    B --> C[Apply RBAC Role Templates]
    C --> D[Inject Pod SecurityContext]
    D --> E[Mount Secrets Securely]
    E --> F[Apply API/OAuth Scopes]
    F --> G[Validate All Outputs]
    G --> H{Validation Passes?}
    H -- Yes --> I[Emit Hardened Artifacts + SecurityImplemented Event]
    H -- No --> J[Emit SecurityViolationDetected + Halt or Retry]

Hold "Alt" / "Option" to enable pan & zoom

🪜 Step-by-Step Breakdown¶

✅ Step 1: Input Aggregation¶

Receives:
trace_id, component_scope, execution_id
component_metadata (image, env, transport)
security_policy_id
Performs schema validation before execution

✅ Step 2: Load Policy Profile¶

Fetches corresponding policy blueprint:
Hardening rules (runAsNonRoot, capabilities)
RBAC roles
Secrets strategy
mTLS enforcement (if enabled)

Failure to resolve policy halts execution.

✅ Step 3: RBAC Role Generation¶

Based on roles defined in policy, create:
role.yaml
rolebinding.yaml
serviceaccount.yaml
Binds service account to deployment

✅ Step 4: Pod Security Context Injection¶

Injects container-level and pod-level securityContext into:
deployment.yaml
Helm values.yaml (if applicable)

Drops all Linux capabilities, disables escalation, enforces seccomp and non-root execution

✅ Step 5: Secret Injection¶

Resolves from policy or VaultResolverAgent:
If env strategy → use envFrom: secretRef
If volumeMount strategy → use projected volumes
Optionally inject sidecar agent config for HashiCorp Vault or Azure Key Vault

✅ Step 6: API Security Enforcement¶

Injects:
OAuth2 scopes
Rate limits
Threat tags
Risk scores
Places in:
Gateway annotations
OpenAPI x-extensions
Pull Request security metadata (via PRCreatorAgent)

✅ Step 7: Validation Phase¶

Validates:
All required fields injected
Policy compliance
YAML schemas valid
RBAC roles do not over-extend permissions
Uses kubectl, OPA, and custom SK-based checkers

✅ Step 8: Emit Outputs¶

Generates:
Hardened YAMLs
Secrets config
Gateway annotations
SecurityImplemented event

If validation fails:

Emit SecurityViolationDetected
Optionally halt pipeline or trigger manual override

⚠️ Guardrails & Triggers¶

Condition	Action
Missing `security_policy_id`	Halt with hard error
Invalid secret mount	Retry with fallback strategy
RBAC role over-privileged	Emit violation, do not bind
Custom override tag	Allows temporary bypass if authorized (`techlead_override: true`)

🧠 Summary¶

The Security Engineer Agent’s process flow is:

🧱 Template-based
🔒 Strict on compliance
🔄 Deterministic and trace-driven
🔔 Event-emitting and telemetry-ready

It guarantees secure, traceable, and reproducible security enforcement across all components in the AI Software Factory.

🧩 Skills and Kernel Functions¶

The Security Engineer Agent uses Semantic Kernel (SK) plugins and custom-built reusable skills to perform:

Enforcement of policy constraints
Artifact injection (YAML, JSON)
Token and RBAC reasoning
Validation of outputs
Emission of traceable events

These functions are executed as modular, composable SK skills, chained through a planner execution graph.

🛠️ Core Skills Used¶

Skill	Purpose
`PolicyResolverSkill`	Loads the appropriate `security_policy_id` definition
`RBACGeneratorSkill`	Generates `role.yaml`, `rolebinding.yaml`, and binds service accounts
`SecurityContextInjectorSkill`	Injects hardened `securityContext` into Kubernetes manifests
`SecretMountInjectorSkill`	Adds secure secret mounts (via env or volume) into deployments
`OAuthScopeMapperSkill`	Adds OAuth2 scopes and x-security metadata to handlers or API layers
`RiskScoringSkill`	Assigns `risk_score` and `threat_tags` to endpoints or sensitive services
`ValidationSkill.Security`	Validates hardening, RBAC, and trace compliance before emitting outputs
`EventEmitterSkill`	Emits `SecurityImplemented` or `SecurityViolationDetected` events to the pipeline

🔁 Example Execution Flow¶

→ PolicyResolverSkill.Resolve(security_policy_id)
→ RBACGeneratorSkill.Generate(component)
→ SecurityContextInjectorSkill.Inject(deployment.yaml)
→ SecretMountInjectorSkill.Inject(secret_refs, env_strategy)
→ OAuthScopeMapperSkill.Inject(api_metadata)
→ ValidationSkill.Security.Validate(all_outputs)
→ EventEmitterSkill.Emit(SecurityImplemented)

💡 Prompt-Based Reasoning (LLM-backed)¶

Function	Description
`TokenScopeRecommender`	Suggests best-fit scopes based on endpoint purpose (e.g., `GET /me` → `user:read`)
`PolicyGapAnalyzer`	Identifies any missed fields or hardening drift compared to baseline profile
`RiskScoreEvaluator`	Evaluates the severity of a given endpoint/service and tags it accordingly

These may be called for suggestive reasoning and refinement, not for primary injection.

🧠 Execution Control with SK Planner¶

The agent dynamically assembles plans based on:

Environment (e.g., prod, qa)
Component type (api, microservice, job)
Blueprint lineage
Policy profile

Example dynamic SK plan:

steps:
  - use RBACGeneratorSkill with profile["scopes"]
  - use SecurityContextInjectorSkill on deployment.yaml
  - use SecretMountInjectorSkill from secret_map.yaml
  - use OAuthScopeMapperSkill if transport == "http"
  - validate with ValidationSkill.Security
  - emit SecurityImplemented

🔒 Built-in Skill Guards¶

Guard	Enforcement
`trace_id` presence	Required in all injected resources
Over-permission detection	Rejects RBACs with wildcard verbs/resources
No-privileged-containers	`cap_add`, `hostPath`, `privileged: true` → blocked
Configurable bypass	Only allowed with `techlead_override: true` in prompt/context

🧠 Summary¶

The Security Engineer Agent’s skills are:

🔧 Composable
🔒 Policy-bound
🎯 Trace-enforced
🧱 Reusable across services and tenants

They ensure that every execution results in secure, validated, and production-safe artifacts, with full traceability back to the blueprint and policy level.

🧰 Core Platform Stack¶

Layer	Technology	Purpose
Agent Runtime	.NET 8 + Semantic Kernel	Host agent skills, planning logic, memory, event execution
LLM Backend	Azure OpenAI (GPT-4 Turbo)	Assist in risk scoring, gap analysis, token scope recommendation
Memory Store	Redis / Cosmos DB / SK Context	Store policy profiles, execution traces, secret mappings
Agent Orchestration	MCP Server	Integrate with upstream and downstream agents via event flow
Container Host	Azure Kubernetes Service (AKS)	Scalable, secure runtime for containerized agent operations

🔐 Security-Specific Tools and Libraries¶

Tool	Use
kubectl	Validate rendered manifests with `--dry-run=client`
OPA / Gatekeeper (optional)	Validate Rego policy compliance in RBAC or seccomp profiles
YAML/Helm processors	Programmatically manipulate manifest files
Azure Key Vault SDK	Resolve secret metadata and mount strategies
HashiCorp Vault Agent Templates	Generate sidecar configurations (if applicable)

📚 Policy and Template Assets¶

Format	Usage
`security-profile.yaml`	Contains RBAC roles, capabilities, claim rules, secret injection models
`rbac-template.yaml`	Templates to render RBAC per role-scope combination
`securityContext.yaml`	Reusable hardened container defaults
`vault-mount.yaml`	Config for volume-based secret mounting or injection agent sidecars

📡 Event and API Interfaces¶

Channel	Description
MCP Event Bus	Emits `SecurityImplemented`, `SecurityViolationDetected`
DevOps Agent Hook	Passes security-enriched YAML to CI pipeline orchestrator
Observability Agent	Forwards spans and risk metadata for dashboard and alerts
GitOps Push Target	Optionally commits generated security files to Git repo (via Pull Request Creator Agent)

📈 Observability Stack¶

Tool	Use
OpenTelemetry SDK	Emit spans (`security.enforce.start`, `.inject`, `.validate`) with trace IDs
Grafana / Azure Monitor	View success rate, violations, RBAC coverage, token scope mappings
Structured JSON Logs	Captured to blob, dashboard, or centralized log sink (via Azure or Loki)

🔐 Security Model Enforced at Agent Level¶

Feature	Description
Policy versioning	`security_policy_id` required per execution, loaded from approved source
Trace-aligned execution	Every file or update includes `trace_id`, `blueprint_id`, `execution_id`
Runtime constraints	RBACs must match roles scoped by service/component scope (e.g., `billing:reader`)
Artifact isolation	Output restricted to workspace or commit scope; no cross-component writing allowed

🔧 Development and Extension Patterns¶

Scenario	Stack
Add new RBAC type	Extend `RBACGeneratorSkill` template with new role definition
Add environment-specific securityContext	Map via overlay profile and `EnvironmentPolicySkill`
Audit override paths	Emit structured `override_used` fields to logs + observability pipeline

🧠 Summary¶

The Security Engineer Agent is built on a cloud-native, trace-first, and policy-bound tech stack, enabling:

Autonomous enforcement of security profiles
Consistent RBAC and identity configuration
Reproducible token scope management
Observability-aware policy execution

This ensures security is not bolted on, but baked in to the ConnectSoft AI Software Factory from blueprint to deployment.

🧾 System Prompt¶

The System Prompt is a foundational instruction injected into the LLM-backed reasoning layer (e.g., GPT-4 Turbo via Semantic Kernel) that governs the agent’s:

Responsibilities
Output structure
Behavioral constraints
Compliance boundaries
Communication tone and enforcement mindset

It defines how the agent interprets the execution context and applies the security policy logic.

🧠 Security Engineer Agent — System Prompt¶

You are the Security Engineer Agent in the ConnectSoft AI Software Factory.

Your role is to enforce traceable, policy-compliant runtime security for microservices, APIs, background jobs, and external-facing components.

You always operate using the security_policy_id provided to you. You must validate that every output adheres to the rules defined in that profile.

You are responsible for:
- Generating RBAC roles and bindings using templates
- Injecting hardened securityContext settings in all container specs
- Mounting secrets via volumes or environment variables using secure references
- Mapping OAuth2 scopes and claims to protected endpoints or handlers
- Adding annotations and labels such as trace_id, blueprint_id, agent_origin, and compliance_tag
- Emitting security telemetry and violations for traceability and observability

You must:
- Never allow privileged, insecure, or wildcarded RBAC permissions
- Never omit trace_id or blueprint_id from artifacts
- Never hallucinate values — use only inputs provided
- Always fail fast and escalate if a required policy field is missing

All of your outputs must be:
- Valid YAML
- Secure by default
- Traceable to the originating blueprint and policy
- Consistent with prior factory-generated components

Do not generate code or handler logic. Focus only on infrastructure, config, and metadata-level security enforcement.

🔐 System Behavior Constraints¶

Rule	Purpose
No hallucinated values	Prevent unauthorized or unverifiable security assignments
Always enforce least privilege	Every RBAC is tightly scoped
Metadata enforcement	Trace ID, policy ID, blueprint ID are mandatory
Audit and escalate	Failures must emit telemetry + optionally notify HumanOpsAgent

📋 Embedded Security Profile Hints (Resolved Prior)¶

The system prompt may reference resolved fields such as:

security_policy_id: sec-profile-auth-api
capabilities: ["DROP_ALL"]
allowPrivilegeEscalation: false
tokenScopes: ["auth:read", "user:email"]
compliance_tag: "pci-dss"

These fields govern enforcement decisions and are not generated, only interpreted and enforced.

🧠 Summary¶

The System Prompt ensures the Security Engineer Agent:

Acts deterministically and securely
Enforces reproducible, traceable, policy-compliant infrastructure
Provides observability and audit hooks with every operation
Integrates seamlessly into the AI Software Factory pipeline

It defines the agent’s operational identity as a non-negotiable enforcer of Zero Trust and traceability.

🧾 Input Prompt Template¶

The Input Prompt Template is a structured, parameterized instruction set fed into the Semantic Kernel planner or LLM. It enables the agent to:

Interpret the security context
Enforce policy without guessing
Bind outputs to a traceable execution scope
Generate secure infrastructure metadata and RBAC policies

This prompt must be deterministic, complete, and trace-linked.

📋 Input Prompt Template (YAML-Injection Style)¶

You are the Security Engineer Agent. You are tasked with applying runtime security to the following component:

Trace ID: {{trace_id}}  
Blueprint ID: {{blueprint_id}}  
Component Name: {{component_name}}  
Component Type: {{component_type}} (e.g., microservice, api, background-job)  
Execution ID: {{execution_id}}  
Target Environment: {{target_environment}}  
Transport: {{transport}} (http, grpc, queue, etc.)

Security Policy ID: {{security_policy_id}}  
Resolved Policy Profile:
{{security_profile_block}}

Component Metadata:
- Container Image: {{container_image}}
- Exposed Ports: {{ports}}
- Secrets: {{secrets_block}}

Your Tasks:
1. Apply RBAC based on the roles in the security profile.
2. Inject hardened securityContext into the container spec.
3. Mount required secrets (as volumes or env vars, per policy).
4. Apply OAuth2 scopes and claims to API endpoints (if applicable).
5. Add traceability metadata to all manifests and outputs.
6. Emit a `SecurityImplemented` event if successful, or `SecurityViolationDetected` on failure.

You must NOT:
- Allow wildcard RBAC
- Skip metadata (trace_id, blueprint_id, policy_id)
- Invent secrets, roles, or scopes not present in the profile or input

🧠 Example Substituted Prompt¶

Trace ID: trace-auth-914  
Blueprint ID: usecase-login-flow  
Component Name: AuthService  
Component Type: microservice  
Execution ID: exec-914-auth  
Target Environment: staging  
Transport: http

Security Policy ID: sec-profile-auth-api

Resolved Policy:
  runAsNonRoot: true
  capabilities: ["DROP_ALL"]
  tokenScopes: ["auth:read", "user:email"]
  vaultMountStrategy: env

Secrets:
  - name: auth-vault-secret
    mountPath: /mnt/secrets/auth
    type: azure-keyvault

📋 Required Template Variables¶

Variable	Description
`{{trace_id}}`	Ties output to blueprint execution trace
`{{security_policy_id}}`	Guides enforcement logic
`{{security_profile_block}}`	Injected policy YAML (from Security Architect Agent)
`{{secrets_block}}`	Secure mapping for vault mounts or env vars
`{{execution_id}}`	Allows telemetry and event correlation
`{{transport}}`	Helps determine if OAuth2 scopes are applicable

📐 Structure Expectations¶

Input Style	Format
Primary	Structured YAML embedded in text prompt
Planner Mode	Semantic Kernel key-value context dict
Multi-step	Automatically expands into planner subgraph execution

🧠 Summary¶

The Input Prompt Template enables the Security Engineer Agent to:

Interpret security context with full trace lineage
Execute deterministically with zero guessing
Align every enforcement to a policy and blueprint
Emit outputs ready for infrastructure and DevOps agents

This ensures automation, compliance, and traceability are guaranteed before a single file is written.

📤 Output Expectations¶

Every output from the Security Engineer Agent must be:

🛡️ Security-enforcing
🔍 Traceable to blueprint, execution, and policy
📄 Valid Kubernetes YAML or Helm-compatible
✅ Validated and schema-compliant
🔔 Observable via emitted events

These outputs feed downstream agents (e.g., Infra, DevOps, Documentation) and are used for compliance audits, CI pipeline hardening, and live runtime validation.

✅ Output Categories & Format¶

1️⃣ Hardened YAML Artifacts¶

🧾 `deployment.yaml` (enriched)¶

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      containers:
        - name: main
          image: ghcr.io/connectsoft/authservice:1.4.2
          envFrom:
            - secretRef:
                name: auth-vault-secret

🧾 `serviceaccount.yaml` (generated if missing)¶

metadata:
  name: authservice-sa
  labels:
    trace_id: trace-auth-914
    agent_origin: security-engineer-agent

🧾 `role.yaml` + `rolebinding.yaml`¶

Generated based on required access scopes:

rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]

2️⃣ Security Metadata Block (in all artifacts)¶

Every generated or updated manifest includes:

metadata:
  annotations:
    trace_id: trace-auth-914
    blueprint_id: usecase-login-flow
    security_policy_id: sec-profile-auth-api
    compliance_tag: pci-dss
    risk_score: 8.2
    agent_origin: security-engineer-agent

3️⃣ API Security Annotations (if applicable)¶

x-security:
  oauth_scopes: [auth:read, user:email]
  rate_limit: 100rps
  mfa_required: true

🔔 4️⃣ Events Emitted¶

✅ `SecurityImplemented`¶

{
  "event": "SecurityImplemented",
  "trace_id": "trace-auth-914",
  "component": "AuthService",
  "policy": "sec-profile-auth-api",
  "artifacts": ["deployment.yaml", "role.yaml", "serviceaccount.yaml"],
  "timestamp": "2025-05-08T00:03:14Z"
}

❌ `SecurityViolationDetected` (on failure)¶

{
  "event": "SecurityViolationDetected",
  "trace_id": "trace-auth-914",
  "reason": "missing securityContext block in deployment",
  "severity": "high",
  "component": "AuthService"
}

🎯 Output Validation Criteria¶

Output Field	Rule
`trace_id`, `blueprint_id`	✅ Required in all manifests
`security_policy_id`	✅ Must match applied profile
`securityContext`	✅ Required unless overridden with flag
`RBAC`	✅ No wildcards, privilege escalation, or empty verbs/resources
`Secrets`	✅ Must resolve from valid source, no hardcoded plaintext

📦 Output Targets¶

Target	Destination
YAML Files	Helm chart overlay, manifest repo, GitOps branch
Event Payloads	MCP Event Bus, ObservabilityAgent, Audit Pipeline
Telemetry Spans	OTEL with tags: `trace_id`, `component_scope`, `status`

🧠 Summary¶

All outputs from the Security Engineer Agent must be:

🔐 Security-enforced
🧭 Trace-bound
📦 Ready for deployment
💬 Auditable by downstream agents
📡 Observable in real-time

They serve as the foundation for Zero Trust security enforcement, CI/CD gates, and agent-based pipeline coordination.

📦 Memory¶

Memory in the Security Engineer Agent allows it to:

Maintain trace linkage and policy version alignment
Reuse previously resolved RBAC and secret configurations
Avoid redundant policy enforcement
Enable rollback, audit, and policy evolution tracking

The agent uses short-term (in-execution) and long-term (persistent) memory layers.

🧠 Short-Term (Execution Memory)¶

Cleared after task completion or timeout. Stored in Semantic Kernel context dictionary.

Key	Description
`trace_id`	Used for tag injection across all outputs
`execution_id`	Links logs, events, telemetry spans
`security_policy_id`	Guides what must be enforced
`component_metadata`	Runtime scope: container image, transport, ports
`overlay_config`	Environment + tenant modifiers (e.g., mount strategy)
`generated_artifacts`	Tracks YAML files created during execution

💾 Long-Term Memory (Persistent)¶

Stored in Redis, Cosmos DB, or Blob/VectorDB depending on tenant and environment.

✅ 1. Trace → Security Profile Map¶

{
  "trace_id": "trace-auth-914",
  "security_policy_id": "sec-profile-auth-api",
  "component": "AuthService",
  "compliance_tag": "pci-dss",
  "applied_at": "2025-05-08T00:03:14Z"
}

Enables audit and enforcement reconciliation.

✅ 2. RBAC Role Registry¶

Key	Purpose
Role ID	Deduplicates RBAC outputs
Scope Hash	Prevents overly broad grants
Reuse Condition	Roles may be reused across components if trace lineage matches and scope is compatible

✅ 3. SecurityContext Template Cache¶

Caches reusable injection fragments by component type + environment
Ensures consistency across microservices of same class
Reduces plan recomposition time

✅ 4. Secret Injection History¶

Tracks which components used which secrets + strategy:

{
  "component": "AuthService",
  "secret_name": "auth-vault-secret",
  "mount_method": "env",
  "last_rotated": "2025-05-06T21:00:00Z"
}

Used to enforce consistency, detect drift, and recommend rotation.

✅ 5. Violation Log Memory (Optional)¶

Used for pattern-based feedback and self-correction.

Violation	Stored Data
`missing securityContext`	Which blueprint, policy, and context caused it
`RBAC wildcard detected`	Source of permission request, auto-escalation trigger

📌 Retention Policies¶

Data Type	Retention
Execution memory	Ephemeral (task lifespan only)
Trace map	180 days minimum
Role registry	365 days with scope pruning
Violation log	90 days or until resolved by Ops agent
Secret access map	180 days (subject to key vault lifecycle)

🔐 Memory Access & Governance¶

Only agents operating in the same trace_id and execution_id domain may access entries
Writes are tagged with agent_origin = security-engineer-agent
No memory mutation allowed after SecurityImplemented is emitted (read-only archival phase)

🧠 Summary¶

The Security Engineer Agent’s memory ensures:

📎 Trace-consistent policy enforcement
🔁 Reusable RBAC and secret mappings
🔍 Auditable security decisions
⚙️ Self-correcting via violation recall

It enables secure automation to operate with context, lineage, and enforcement history — a key pillar of ConnectSoft’s traceable, Zero Trust software factory.

🔍 Validation¶

The Security Engineer Agent must confirm that all outputs:

Meet the assigned security policy profile
Are Kubernetes-valid and Helm-safe
Include all traceability and compliance metadata
Do not contain security anti-patterns or violations

This validation is enforced pre-commit, pre-event emission, and optionally again pre-deploy.

✅ Categories of Validation¶

🧾 1. Schema & Syntax Validation¶

Check	Tool
YAML valid	`kubectl apply --dry-run=client`
Helm charts	`helm template` + `helm lint` (if applicable)
Manifest format	`yamllint`, internal structure assertions

🔒 2. Security Enforcement Validation¶

Requirement	Rule
`securityContext.runAsNonRoot`	Must be `true` unless explicitly overridden
`allowPrivilegeEscalation`	Must be `false`
`capabilities.drop`	Must include `"ALL"` or strict subset
No `hostPath`, `hostNetwork`, or `privileged: true`	Disallowed unless policy allows it
`seccompProfile.type`	Must be `RuntimeDefault` or `Localhost` scoped by policy

📜 3. RBAC Scope Validation¶

Rule	Enforcement
Wildcard verbs/resources	Blocked unless profile override is present
Empty verbs/resources	Considered incomplete — triggers warning
RBAC limited to service-specific namespace	Required unless global service explicitly declared
`serviceAccount` linkage	Required in deployment or statefulset manifest

🧠 4. Metadata Completeness¶

Every artifact must contain:

annotations:
  trace_id: <required>
  blueprint_id: <required>
  security_policy_id: <required>
  agent_origin: security-engineer-agent

Missing any of the above = hard validation failure.

🔐 5. Secrets Validation¶

Check	Rule
Secret source registered	Must exist in vault resolver memory
Mount path	Must match policy-defined prefix (e.g., `/mnt/secrets/*`)
No hardcoded secrets in `env.value`	Allowed only via `env.valueFrom.secretRef`

🧬 6. Policy Conformance (Gap Scan)¶

Invokes PolicyGapAnalyzerSkill (optional, LLM-assisted) to:

Compare generated artifacts to full policy definition
Identify any drift, gaps, or omissions (e.g., missing risk_score, missing RBAC link)

❌ 7. Failure Handling¶

Failure Type	Action
YAML syntax or schema	Block execution, emit `SecurityViolationDetected`
Policy violation	Halt, log violation, escalate via HumanOpsAgent
RBAC over-privilege	Reject role, notify Security Architect Agent
Missing required metadata	Abort before emitting artifacts
Hardcoded secrets	Remove env entry, fail and retry if source available

🧠 Example Validation Failure Output¶

{
  "event": "SecurityViolationDetected",
  "reason": "Missing runAsNonRoot in deployment.yaml",
  "component": "UserService",
  "severity": "high",
  "policy": "sec-profile-default",
  "trace_id": "trace-user-888",
  "timestamp": "2025-05-08T00:09:47Z"
}

✅ 8. Final Validation Summary¶

Area	Must Pass
✅ YAML format & schema	Yes
✅ securityContext integrity	Yes
✅ RBAC scope bounds	Yes
✅ Metadata tags present	Yes
✅ Trace & policy ID included	Yes
✅ Secrets resolved from vault	Yes

🧠 Summary¶

The Security Engineer Agent’s validation system ensures:

Every artifact is secure, traceable, and compliant
No configuration makes it to production without enforcement
Any failure is traceable and actionable via events, logs, and dashboards

Validation is the final gate before the outputs become part of the real-world infrastructure.

🔁 Retry & Correction Flow¶

The Security Engineer Agent operates within a fail-safe, trace-aware retry model to ensure:

Transient issues don’t block execution
Policy violations don’t silently pass
Violations are escalated properly
Traceability is preserved through all error cycles

It includes both automated retry logic and manual override support.

🔄 Retryable Error Categories¶

Error Type	Strategy
Secret mount strategy failure	Retry with alternate (e.g., `env` → `volumeMount`)
Policy fetch timeout	Retry up to 3 times with exponential backoff
Vault connector unavailable	Delay + retry or fallback to sealed secret
LLM gap scan timeout	Skip suggestive step, proceed with hard rules

🚫 Non-Retryable / Hard Failures¶

Failure	Action
Missing `security_policy_id`	Abort immediately
RBAC over-privilege	Emit `SecurityViolationDetected`, block commit
Hardcoded plaintext secrets	Remove and fail — requires human correction
Metadata tag missing	Fail validation phase and halt emission
Disabled enforcement (flagged trace)	Log but skip enforcement (for testing only)

🪜 Retry Flow Logic¶

flowchart TD
    A[Start Enforcement] --> B[Inject Security Fields]
    B --> C[Validate Outputs]
    C --> D{Validation Passed?}
    D -- Yes --> E[Emit SecurityImplemented]
    D -- No --> F{Retryable?}
    F -- Yes --> B
    F -- No --> G[Emit SecurityViolationDetected + Escalate]

Hold "Alt" / "Option" to enable pan & zoom

📄 Retry Policy Configuration¶

retry_policy:
  max_attempts: 3
  backoff_strategy: exponential
  delay_ms: 500
  retryable_failures:
    - vault_resolution_timeout
    - helm_patch_render_error
    - overlay_injection_conflict

🧩 Correction Strategies (Auto + Manual)¶

✅ Auto-Correction Patterns¶

Violation	Fix
`missing serviceAccount`	Generate and bind a default one
`invalid secret mountPath`	Rewrite to conform to `/mnt/secrets/<name>`
`missing runAsNonRoot`	Inject from default security profile
`risk_score missing`	Backfill with calculated default from policy

Auto-corrections are always logged and tagged in telemetry.

👤 Manual Correction Paths¶

When automatic resolution fails or is not allowed:

Emit SecurityViolationDetected
Notify:
HumanOpsAgent
TechLeadAgent
Security Architect Agent (if policy mismatch)

They may choose to:

Retry with override flag
Supply updated policy or secret mapping
Accept limited or non-hardened deployment (flagged as exception)

🧠 Correction Telemetry¶

Each correction attempt is logged and included in observability:

{
  "correction": "auto-injected securityContext.runAsNonRoot",
  "agent": "security-engineer-agent",
  "trace_id": "trace-user-888",
  "attempt": 2,
  "status": "resolved"
}

✅ Summary¶

The Security Engineer Agent’s retry and correction system ensures:

Resilience against common security enforcement edge cases
Deterministic outputs when auto-fix is successful
Safe halting when traceability or compliance is at risk
Full transparency to downstream agents and human stakeholders

It enables the agent to act as a responsible, policy-aligned security enforcer — never bypassing violations, always escalating properly.

🤝 Collaboration Interfaces¶

The Security Engineer Agent is a mid-pipeline enforcement node in the agentic execution flow. It does not operate in isolation — it:

Receives design directives from the architecture layer
Applies enforcement in tandem with microservice and infrastructure agents
Pushes hardened outputs to DevOps, observability, and PR systems
Shares responsibility for secure delivery alongside the HumanOps and Audit pipeline

🔗 Position in Execution Flow¶

flowchart TD
    ArchSec[Security Architect Agent]
    MicroGen[Microservice Generator Agent]
    InfraEng[Infrastructure Engineer Agent]
    SecEng[Security Engineer Agent]
    DevOps[DevOps Agent]
    HumanOps[HumanOps Agent]
    Observability[Observability Agent]
    PR[Pull Request Creator Agent]

    ArchSec --> SecEng
    MicroGen --> SecEng
    InfraEng --> SecEng
    SecEng --> InfraEng
    SecEng --> DevOps
    SecEng --> Observability
    SecEng --> PR
    SecEng --> HumanOps

Hold "Alt" / "Option" to enable pan & zoom

📥 Upstream Dependencies¶

Agent	Purpose
Security Architect Agent	Supplies `security_policy_id`, enforcement templates, RBAC definitions
Microservice Generator Agent	Provides `component_metadata`, `trace_id`, handler declarations
Infrastructure Engineer Agent	Provides `deployment.yaml`, `configmap.yaml`, environment overlays

📤 Downstream Integrations¶

Agent / System	Role
InfraEng	Receives hardened and validated manifests for Helm/YAML packaging
DevOps Agent	Receives secure-ready artifacts for staging and deployment
Observability Agent	Receives risk tags, telemetry spans, security event signals
Pull Request Creator Agent	Includes hardened diffs, security metadata block in PR body
HumanOps Agent	Receives `SecurityViolationDetected` signals for policy failure or misconfiguration
Test Generator Agent (optional)	Can receive OAuth2 scope metadata to generate security-focused test cases

🔁 Events and Contracts¶

✅ Events Emitted¶

Event	Consumed By
`SecurityImplemented`	InfraEng, DevOpsAgent, ObservabilityAgent
`SecurityViolationDetected`	HumanOpsAgent, Security Architect Agent
`TraceLinkValidated` (optional)	Audit agents or PR annotators

🧠 Context Propagation¶

Context Element	Shared With
`trace_id`, `blueprint_id`, `execution_id`	All linked agents (Observability, DevOps, PR)
`security_policy_id`	Included in all emitted YAML and event payloads
`agent_origin: security-engineer-agent`	Used by other agents for traceability and audit attribution

📡 Optional Collaboration Extensions¶

Integration	Benefit
`VaultResolverAgent`	Maps dynamic secrets or token issuers to correct mount path
`Compliance Scorer Agent`	Adds risk scoring and security benchmark scoring per component
`Changelog Generator Agent`	Summarizes applied security changes for audit exports or compliance logs

Channel	Output
Git (Helm/YAML)	Secure manifests versioned alongside other agent outputs
Blob / Artifact Repo	Hardened assets for compliance snapshots
CI Pipeline Input	Tags and gates added by DevOps Agent using security metadata

✅ Summary¶

The Security Engineer Agent is a collaborative enforcer that:

Embeds deeply into the factory pipeline
Enforces policies handed down from architecture
Prepares security-hardened artifacts for delivery
Emits structured signals to enable secure release, observability, and audit trails

It is a connector, validator, and guardian, bridging enforcement and traceable output across the software supply chain.

📡 Observability & Human Intervention Hooks¶

The Security Engineer Agent must be:

🧭 Traceable in every execution
🔍 Observable through telemetry and events
👤 Interruptible by authorized humans (when required)
🧠 Self-auditing with event logging and span correlation

These capabilities allow ConnectSoft to enforce Zero Trust security while still enabling safe overrides and insights across large-scale multi-tenant execution.

📈 OpenTelemetry Spans¶

Emitted Spans¶

Span Name	Description
`security.enforcement.start`	Start of enforcement execution
`security.inject.rbac`	Role + rolebinding injection
`security.inject.securityContext`	securityContext added to deployment
`security.inject.secret`	Secrets mounted or injected via env/volumes
`security.validate.outputs`	Validation phase prior to emitting
`security.complete`	Emit success or failure signal

Span Tags¶

trace_id: trace-abc-123
component: AuthService
security_policy_id: sec-profile-auth-api
agent: security-engineer-agent
status: success | failed
failure_reason: (if any)
risk_score: 8.2

📊 Structured Logging (JSON)¶

All actions are logged to central observability and blob:

{
  "agent": "security-engineer-agent",
  "trace_id": "trace-user-888",
  "component": "UserService",
  "policy": "sec-profile-default",
  "status": "SecurityImplemented",
  "timestamp": "2025-05-08T00:12:03Z"
}

Failures, retries, and corrections are included with event_type: correction, violation, or override.

📣 Lifecycle Events¶

✅ `SecurityImplemented`¶

Signals enforcement succeeded, with all required tags and validations.

❌ `SecurityViolationDetected`¶

Signals a hard failure (e.g., missing securityContext, wildcard RBAC). Includes:

Reason (machine-readable)
Severity
Artifact path
Resolution suggestion (if detected)

👥 Human Intervention Hooks¶

Triggered when automatic retry/correction fails or a policy is intentionally violated.

Stakeholder	Role
HumanOpsAgent	Reviews violations, triggers override, or blocks release
TechLeadAgent	May override policy profile per tenant/project scope
Security Architect Agent	Notified for enforcement drift, role creation gaps, or repeated violations

🔐 Override Mechanism¶

Overrides are only allowed when:

techlead_override: true is present in input context
override_reason is explicitly logged
Resulting artifacts are tagged as:

annotations:
  override_applied: true
  approved_by: TechLeadAgent
  override_reason: "OAuth2 scopes in flux"

🧠 Manual Retry Interface¶

Interface	Action
MCP Dashboard	Retry with updated inputs or toggled flags
GitHub PR Comment	Retry triggered on `/retry-security-enforcement` command
Slack Notification	Summary + action buttons to accept/reject overrides

📉 Failure Dashboard & Metrics¶

Provided by Observability Agent:

% of violations auto-corrected
Avg enforcement duration
Risk score distribution across services
Per-tenant compliance heatmap

✅ Summary¶

The Security Engineer Agent’s observability and intervention system ensures:

🔍 Transparent, real-time execution insights
🧠 Smart telemetry on both successes and failures
👥 Controlled escalation paths to humans when policy cannot be enforced
🔐 Strong override governance with full traceability

It delivers on the ConnectSoft mandate: “Secure by default, auditable by design.”

🛡️ Security Engineer Agent Coordination Layer Diagram¶

flowchart TD

  subgraph Architecture Layer
    A1[Security Architect Agent]
  end

  subgraph Software Engineering
    B1[Microservice Generator Agent]
    B2[Infrastructure Engineer Agent]
    B3[Pull Request Creator Agent]
  end

  subgraph Security Enforcement
    C1[Security Engineer Agent]
  end

  subgraph Delivery and Monitoring
    D1[DevOps Agent]
    D2[Observability Agent]
    D3[HumanOps Agent]
  end

  A1 --> C1
  B1 --> C1
  B2 --> C1

  C1 --> B2
  C1 --> B3
  C1 --> D1
  C1 --> D2
  C1 --> D3

Hold "Alt" / "Option" to enable pan & zoom

🧭 Diagram Explanation¶

Flow	Description
🧩 A1 → C1	Security policies, profiles, RBAC templates from Security Architect Agent
🏗️ B1 → C1	Component metadata and handler definitions from Microservice Generator Agent
⚙️ B2 → C1	Deployment YAML and overlays from Infrastructure Engineer Agent
🔧 C1 → B2	Hardened manifests and injected securityContext, secrets
🔐 C1 → B3	Adds security metadata into the PR (trace ID, scopes, policy ID)
🚀 C1 → D1	Delivers secure-ready manifests and RBACs to DevOps Agent
📊 C1 → D2	Emits spans and events to Observability Agent (risk scores, violations)
📣 C1 → D3	Sends violation reports or correction needs to HumanOps Agent

🧠 Security Engineer Agent Specification¶

🎯 Agent Purpose¶

🛠️ Responsibilities¶

🔗 Execution Flow Integration Diagram¶

🧩 Role Within the Factory Lifecycle¶

🔖 Example Outcome¶

✅ Summary¶

🧰 Core Responsibilities¶

🔐 Execution-Level Deliverables¶

✅ 1. RBAC Role and Binding Injection¶

✅ 2. Token Scope and OAuth Rule Mapping¶

✅ 3. Pod SecurityContext Enforcement¶

✅ 4. Secret Management¶

✅ 5. API Gateway Security Annotations¶

✅ 6. Audit Metadata Injection¶

✅ 7. Event Emission¶

📌 Summary Table of Deliverables¶

🧠 Summary¶

📥 Inputs¶

🔐 Primary Inputs¶

✅ 1. Trace Context¶

✅ 2. Security Policy Definition¶

✅ 3. Component Metadata¶

✅ 4. Kubernetes Deployment Template (Pre-enforcement)¶

✅ 5. Secrets Registry Mapping¶

✅ 6. API Gateway Access Definitions¶

✅ 7. Environment Profile¶

📂 Optional Inputs¶

🧠 Input Integration Summary¶

🧠 Summary¶

📤 Outputs¶

✅ 1. Hardened Kubernetes Resources¶

🧾 Updated deployment.yaml¶

🧾 Adds serviceaccount.yaml¶

🧾 Adds role.yaml and rolebinding.yaml¶

✅ 2. Secret Injection Configuration¶

✅ 3. API Security Metadata Block¶

✅ 4. Annotations & Labels for Auditability¶

✅ 5. Event: SecurityImplemented¶

❌ Event: SecurityViolationDetected (optional)¶

📦 Optional Outputs¶

🧠 Summary¶

📚 Knowledge Base¶

🧾 Categories of Knowledge¶

✅ 1. Security Profiles (Policy Blueprints)¶

✅ 2. RBAC Role Templates¶

✅ 3. SecurityContext Injection Blocks¶

✅ 4. Secrets Injection Patterns¶

✅ 5. OAuth2 Scope Annotations¶

✅ 6. Security Labels & Trace Fields¶

✅ 7. Helm Security Overlays (optional)¶

📘 Storage and Access¶

🔒 Governance¶

🧠 Summary¶

🔄 Process Flow¶

🪜 Step-by-Step Breakdown¶

✅ Step 1: Input Aggregation¶

✅ Step 2: Load Policy Profile¶

✅ Step 3: RBAC Role Generation¶

✅ Step 4: Pod Security Context Injection¶

✅ Step 5: Secret Injection¶

✅ Step 6: API Security Enforcement¶

✅ Step 7: Validation Phase¶

✅ Step 8: Emit Outputs¶

⚠️ Guardrails & Triggers¶

🧠 Summary¶

🧩 Skills and Kernel Functions¶

🛠️ Core Skills Used¶

🔁 Example Execution Flow¶

💡 Prompt-Based Reasoning (LLM-backed)¶

🧠 Execution Control with SK Planner¶

🔒 Built-in Skill Guards¶

🧠 Summary¶

🧰 Core Platform Stack¶

🔐 Security-Specific Tools and Libraries¶

📚 Policy and Template Assets¶

📡 Event and API Interfaces¶

📈 Observability Stack¶

🔐 Security Model Enforced at Agent Level¶

🔧 Development and Extension Patterns¶

🧾 Updated `deployment.yaml`¶

🧾 Adds `serviceaccount.yaml`¶

🧾 Adds `role.yaml` and `rolebinding.yaml`¶

✅ 5. Event: `SecurityImplemented`¶

❌ Event: `SecurityViolationDetected` (optional)¶

🧾 `deployment.yaml` (enriched)¶

🧾 `serviceaccount.yaml` (generated if missing)¶

🧾 `role.yaml` + `rolebinding.yaml`¶

✅ `SecurityImplemented`¶

❌ `SecurityViolationDetected` (on failure)¶