NIST Agent Identity

NIST Agent Identity & COSAiS Pre-Alignment Guide

Guia del AI-First Engineering Framework v7.6.0

Version: 1.0.0 | Fecha: Marzo 2026 Estado: ACTIVO Aplica a: F08 Security, F09 Operations — transversal para proyectos con agentes AI Referencia principal: Compliance_Regulatory_Alignment_Guide.md (seccion 9)

---

1. Introduccion

NIST (National Institute of Standards and Technology) esta desarrollando marcos de seguridad especificos para sistemas AI agenticos. Esta guia detalla como el framework Baseline se alinea con los conceptos de identidad, autorizacion, delegacion y accountability de NIST, y como prepararse para el overlay COSAiS antes de su publicacion oficial.

Audiencia: equipos que operan agentes AI autonomos (FABs, multi-agent, MCP integrations) y necesitan demostrar cumplimiento ante clientes federales USA, auditorias enterprise o certificaciones.

---

2. NIST AI RMF — Las 4 Funciones Aplicadas a Agentes

El AI Risk Management Framework (AI RMF 1.0, enero 2023) define cuatro funciones. Para sistemas agenticos, la implementacion requiere controles adicionales:

Funcion	Descripcion	Mapping al Framework	Artefacto(s)
GOVERN	Politicas, roles, accountability	7 Golden Principles, RACI	AGENTS.md, human_agent_responsibility.yaml
MAP	Contexto, stakeholders, riesgos	Analisis de dominio, clasificacion	project-config.yaml, compliance_matrix.yaml
MEASURE	Metricas, evaluacion, monitoreo	DORA + evals + scorecards	dora-metrics.py, evaluation_scorecard.yaml
MANAGE	Respuesta, mitigacion, mejora	Kill switch, feedback loops	fab-kill-switch.sh, improvement_backlog.yaml

2.1 Mapping Detallado: GOVERN — Politicas y Accountability

La funcion GOVERN establece la cultura organizacional de gestion de riesgos AI. El framework implementa esta funcion a traves de artefactos declarativos que definen politicas, permisos y limites.

Subcategoria GOVERN	Descripcion	Artefacto del Framework	Que Implementa
GOV-1: Politicas AI	Politicas organizacionales para uso de AI	AGENTS.md	7 Golden Principles, boundaries (Never/Ask First/Always), disclosure
GOV-2: Accountability	Roles y responsabilidades claras	CORE_F00_Roles_RACI_Gates.md	RACI completo por fase, Golden Principle 4 (humano responsable)
GOV-3: Autorizacion	Permisos y controles de acceso	settings.json	permissions.deny/permissions.allow, deny-by-default
GOV-4: Limites autonomos	Limites de autonomia del agente	.fab-config.yaml	Budget caps, max_concurrent, mode (headless/interactive)
GOV-5: Acceso a modelos	Politicas de acceso a modelos AI	gateway_policy.yaml	Rate limiting, allowed models, audit logging
GOV-6: Responsabilidad humano/agente	Definicion explicita de responsabilidades	human_agent_responsibility.yaml	Tareas del humano vs agente, escalation protocol

2.2 Mapping Detallado: MAP — Identificacion de Riesgos

La funcion MAP contextualiza los riesgos AI del proyecto. El framework proporciona artefactos para identificar, clasificar y registrar riesgos desde multiples angulos.

Subcategoria MAP	Descripcion	Artefacto del Framework	Que Implementa
MAP-1: Riesgos regulatorios	Identificar requisitos de compliance	compliance_matrix.yaml	Mapping EU AI Act, ISO 42001, NIST por clausula/articulo
MAP-2: Riesgos de seguridad AI	Vulnerabilidades especificas de AI	owasp-asi-checker.py	ASI01-ASI10 automated checks, reporte de hallazgos
MAP-3: Inventario de componentes	Que modelos/datos/tools se usan	aibom.yaml (via aibom-generator.py)	AI Bill of Materials: modelos, datasets, APIs, licencias
MAP-4: Evaluacion de aptitud AI	Viabilidad del enfoque AI	problem_statement.yaml	AI fit assessment, riesgos de negocio, alternativas
MAP-5: Clasificacion de datos	Sensibilidad de datos usados	data_classification.yaml	Niveles: public/internal/confidential/restricted/prohibited
MAP-6: Provenance de datos	Origen y lineage de datos AI	data_provenance_registry.yaml	Fuente, licencia, quality_score, transformaciones
MAP-7: Riesgos de terceros	Dependencias externas AI	mcp-security-audit.py	Auditoria de MCP servers: trust, auth, transport

2.3 Mapping Detallado: MEASURE — Metricas y Evaluacion

La funcion MEASURE cuantifica los riesgos y el desempeno del sistema AI. El framework automatiza la medicion a traves de scripts y templates de evaluacion.

Subcategoria MEASURE	Descripcion	Artefacto del Framework	Que Implementa
MSR-1: Metricas de delivery	Velocidad y estabilidad del equipo	dora-metrics.py	DORA (DF, LT, CFR, MTTR) + SPACE con atribucion AI
MSR-2: Evaluacion de modelos	Rendimiento de modelos AI	evaluation_scorecard.yaml	Baselines, umbrales, regression detection
MSR-3: Compliance automatizado	Nivel de cumplimiento normativo	compliance-linter.py	15 reglas, scoring 0-100, reporte por track
MSR-4: Seguridad AI	Postura de seguridad agentica	owasp-asi-checker.py	ASI01-ASI10 con severidad (critical/high/medium/low)
MSR-5: Rendimiento de builders	Eficacia de agentes autonomos	fab-eval-builders.py	Promote/tune/retire basado en metricas
MSR-6: Validacion de artefactos	Integridad de la documentacion	artifact-validator.py	YAML vs 42 JSON schemas

2.4 Mapping Detallado: MANAGE — Respuesta y Mitigacion

La funcion MANAGE define como responder a riesgos materializados y como mejorar continuamente. El framework implementa mecanismos de respuesta automatica y manual.

Subcategoria MANAGE	Descripcion	Artefacto del Framework	Que Implementa
MNG-1: Emergency stop	Parada de emergencia de agentes	fab-kill-switch.sh	STOP signal, graceful shutdown, auto-checkpoint
MNG-2: Circuit breakers	Limites de costo automaticos	fab-cost-guard.py	Niveles green/yellow/red/critical, auto-signal
MNG-3: Reporte de incidentes	Documentacion de incidentes AI	incident_reporting_plan.yaml	Clasificacion, notificacion, EU AI Act Art.73
MNG-4: Mejora continua	Backlog priorizado de mejoras	improvement_backlog.yaml	Root cause analysis, prioridad, responsable
MNG-5: Feedback automatizado	Ciclo telemetria → mejora	fab-feedback-loop.py	Analisis → auto-generacion de intents de mejora
MNG-6: Monitoreo operacional	Salud de agentes activos	fab-health-check.sh	Status, uptime, errores de FABs activos

2.5 Tabla Resumen: Mapping Completo NIST AI RMF → Framework

Funcion	Artefactos de Politica	Artefactos de Datos	Scripts de Enforcement	Template de Tracking
GOVERN	AGENTS.md, settings.json, .fab-config.yaml, gateway_policy.yaml	human_agent_responsibility.yaml	gate-check.sh	nist_rmf_functions.yaml (govern)
MAP	compliance_matrix.yaml, problem_statement.yaml	aibom.yaml, data_classification.yaml, data_provenance_registry.yaml	aibom-generator.py, owasp-asi-checker.py, mcp-security-audit.py	nist_rmf_functions.yaml (map)
MEASURE	evaluation_scorecard.yaml	dora_metrics_config.yaml	dora-metrics.py, compliance-linter.py, fab-eval-builders.py, artifact-validator.py	nist_rmf_functions.yaml (measure)
MANAGE	incident_reporting_plan.yaml, improvement_backlog.yaml	DISCOVERIES.md	fab-kill-switch.sh, fab-cost-guard.py, fab-feedback-loop.py, fab-health-check.sh	nist_rmf_functions.yaml (manage)

Template de tracking: Para registrar el estado de alineacion por funcion, usar project/F08_security/nist_rmf_functions.yaml.

---

3. Agent Identity Model

3.1 Identidad del agente

Cada agente en el framework tiene identidad declarativa compuesta por:

Componente	Donde se define	Ejemplo
Nombre unico	AGENTS.md seccion del agente	@architect, @qa_engineer
Rol y capacidades	AGENTS.md + .claude/agents/	”Disenar arquitectura, evaluar ADRs”
Limitaciones explicitas	AGENTS.md Boundaries (Never list)	“No modificar baseline/, no commitear secrets”
Metadata operacional	.fab-coordination.yaml	agent_id, current_task, status

3.2 Autorizacion

El framework implementa autorizacion granular por multiples capas:

Capa	Mecanismo	Artefacto
Permisos por herramienta	permissions.deny / permissions.allow	settings.json
Permisos por skill	allowed-tools en frontmatter	.claude/skills/*/SKILL.md
Permisos por sesion	Session-scoped, no persistentes	settings.json per session
Minimo privilegio	Deny-by-default + explicit allow	settings.json + rules
Revocacion inmediata	Kill switch + signal files	fab-kill-switch.sh

3.3 Delegacion

Cuando un agente delega trabajo a otro (multi-agent, FAB coordinator):

Concepto NIST	Implementacion	Artefacto
Task decomposition	Intent → subtasks via coordinator	fab-coordinator.py
Scope limitado	Budget + permissions por intent	.fab-config.yaml
Cadena verificable	Intent → plan → execution → checkpoint	progress-tracker.md
No-transitividad	Skills no pueden lanzar otros agentes	settings.json
Revocacion	STOP signal + graceful shutdown	fab-kill-switch.sh

3.4 Accountability

Concepto NIST	Implementacion	Artefacto
Trazabilidad	Co-authorship en git commits	git log
Cadena de responsabilidad	RACI + Golden Principle 4 (humano responsable)	AGENTS.md, RACI
Audit trail inmutable	Git history + Langfuse traces	Observability Guide
Forense post-incidente	Session replays + checkpoints	HANDOFF.md, progress-tracker.md

---

4. SP 800-53 — Familias de Control Relevantes para Agentes AI

NIST SP 800-53 Rev. 5 define controles de seguridad organizados en familias. Para sistemas AI agenticos, seis familias son prioritarias:

4.1 Tabla de mapping: SP 800-53 → Framework Baseline

Familia	ID	Nombre	Controles clave para agentes	Artefacto del framework
AC	Access Control	Control de acceso	AC-2 (gestion de cuentas), AC-3 (enforcement), AC-6 (minimo privilegio), AC-17 (acceso remoto)	settings.json, .fab-coordination.yaml, gateway_policy.yaml
AU	Audit & Accountability	Auditoria	AU-2 (eventos auditables), AU-3 (contenido de registros), AU-6 (revision de audit), AU-12 (generacion)	dora-metrics.py, compliance-linter.py, Langfuse traces
IA	Identification & Auth	Identificacion	IA-2 (identificacion), IA-4 (gestion de identificadores), IA-8 (identificacion no-org)	AGENTS.md, agent cards (A2A), .fab-coordination.yaml
IR	Incident Response	Respuesta a incidentes	IR-4 (manejo), IR-5 (monitoreo), IR-6 (reporte)	fab-kill-switch.sh, incident_reporting_plan.yaml, EU AI Act Art.73
SA	System Acquisition	Adquisicion de sistemas	SA-4 (proceso de adquisicion), SA-9 (servicios externos), SA-11 (testing)	aibom.yaml, data_provenance_registry.yaml, sast_sca_config.yaml
SI	System Integrity	Integridad del sistema	SI-2 (remediacion de fallas), SI-3 (proteccion contra codigo malicioso), SI-7 (integridad de software)	sast-sca-scanner.py, artifact-validator.py, owasp-asi-checker.py

4.2 Detalle por familia

AC — Access Control

Control	Descripcion	Implementacion en Framework
AC-2	Gestion de cuentas de agentes	Agent IDs en AGENTS.md, lifecycle en .fab-coordination.yaml
AC-3	Enforcement de acceso	settings.json permissions (deny/allow), rules por directorio
AC-6	Minimo privilegio	Deny-by-default, skills con allowed-tools explicitos
AC-17	Acceso remoto	MCP transport security (TLS), OAuth 2.1 para MCP remoto

AU — Audit & Accountability

Control	Descripcion	Implementacion en Framework
AU-2	Eventos auditables	Git commits con co-authorship, DORA metrics, eval results
AU-3	Contenido de registros	Langfuse traces (input/output/latency/cost), checkpoints
AU-6	Revision de registros	compliance-linter.py automated scan, dashboards
AU-12	Generacion de audit	dora-metrics.py genera metricas desde git history

IA — Identification & Authentication

Control	Descripcion	Implementacion en Framework
IA-2	Identificacion de agentes	Nombre + rol + capabilities en AGENTS.md
IA-4	Gestion de identificadores	Agent cards (A2A protocol), .fab-coordination.yaml agent_id
IA-8	Identificacion de agentes externos	MCP server registry, AIBOM para modelos de terceros

IR — Incident Response

Control	Descripcion	Implementacion en Framework
IR-4	Manejo de incidentes	fab-kill-switch.sh (emergency stop + graceful shutdown)
IR-5	Monitoreo de incidentes	fab-health-check.sh, circuit breakers en fab-cost-guard.py
IR-6	Reporte de incidentes	incident_reporting_plan.yaml, EU AI Act Art.73 compliance

SA — System Acquisition

Control	Descripcion	Implementacion en Framework
SA-4	Proceso de adquisicion	aibom-generator.py documenta componentes AI adquiridos
SA-9	Servicios externos	data_provenance_registry.yaml, MCP security audit
SA-11	Testing de desarrollador	sast-sca-scanner.py, owasp-asi-checker.py, eval scorecards

SI — System Integrity

Control	Descripcion	Implementacion en Framework
SI-2	Remediacion de fallas	sast-sca-scanner.py con auto-scan, remediation tracking
SI-3	Proteccion contra codigo malicioso	Pre-commit hooks (secret scanning), sandbox execution
SI-7	Integridad de software	artifact-validator.py (YAML vs schema), git integrity

---

5. NIST COSAiS — Pre-Alineacion

5.1 Que es COSAiS

COSAiS (Cybersecurity of Standalone AI Systems) es un overlay de seguridad en desarrollo por NIST, basado en SP 800-53 Rev. 5, disenado para aplicarse a sistemas AI que operan con autonomia significativa — incluyendo agentes AI, sistemas multi-agente y pipelines de AI agentica.

• Base normativa: SP 800-53 Rev. 5 (controles de seguridad)
• Formato: Overlay (controles adicionales y parametrizaciones especificas para AI)
• Estado esperado: Draft publico estimado para Q3-Q4 2026
• Audiencia: Agencias federales USA, contratistas de defensa, organizaciones que adopten NIST voluntariamente
• Contexto: Complementa AI RMF 1.0, NIST AI 600-1 (Generative AI Profile), y el RFI de Agent Identity (marzo 2026)

5.2 Por que importa ahora

1. Adopcion anticipada: organizaciones que se alineen antes tendran ventaja competitiva en contratos federales
2. Convergencia regulatoria: EU AI Act, ISO 42001 y NIST convergen en los mismos conceptos (identidad, oversight, audit trail)
3. Costo de remediacion: alinearse post-publicacion es 3-5x mas costoso que pre-alinearse
4. Efecto cascada: contratos enterprise y B2B estan empezando a requerir evidencia de alineacion NIST para AI

5.3 Areas de overlay esperadas

Basado en publicaciones previas de NIST (AI RMF, AI 600-1, RFI Agent Identity), las areas de overlay anticipadas son:

Area COSAiS esperada	Familias SP 800-53	Pre-alineacion en Framework
Identidad de agentes	IA, AC	AGENTS.md, .fab-coordination.yaml, agent cards A2A
Autorizacion dinamica	AC	settings.json deny-by-default, JIT tokens
Cadena de delegacion	AC, AU	fab-coordinator.py, progress-tracker.md
Audit trail agentico	AU	dora-metrics.py, git co-authorship, Langfuse
Respuesta a incidentes AI	IR	fab-kill-switch.sh, circuit breakers
Supply chain AI	SA	aibom-generator.py, data_provenance_registry.yaml
Integridad de modelos	SI	sast-sca-scanner.py, eval scorecards
Oversight humano	AC, AU	human_agent_responsibility.yaml, escalation protocol

---

6. Checklist de Pre-Alineacion

Acciones que los equipos deben tomar ahora para estar listos cuando COSAiS se publique:

6.1 Identidad y acceso (AC + IA)

• Todos los agentes tienen identidad declarativa en AGENTS.md
• settings.json usa deny-by-default con allow explicito
• Skills tienen allowed-tools definidos en frontmatter
• Agent cards A2A estan generadas para agentes que exponen APIs
• .fab-coordination.yaml tiene agent_id unico por agente activo

6.2 Auditoria (AU)

• Git commits incluyen co-authorship de agentes AI
• dora-metrics.py esta configurado para el proyecto
• Langfuse (u observabilidad equivalente) captura traces de agentes
• compliance-linter.py corre en CI con score minimo configurado

6.3 Respuesta a incidentes (IR)

• fab-kill-switch.sh esta disponible y testeado
• fab-cost-guard.py tiene circuit breakers configurados
• incident_reporting_plan.yaml esta completado
• Equipo conoce el procedimiento de emergency stop

6.4 Supply chain (SA)

• AIBOM generado con aibom-generator.py
• data_provenance_registry.yaml documenta todas las fuentes de datos AI
• MCP servers auditados con mcp-security-audit.py
• Dependencias escaneadas con sast-sca-scanner.py

6.5 Integridad (SI)

• Pre-commit hooks activos (secret scanning, YAML validation)
• artifact-validator.py corre contra schemas
• Eval scorecards establecidos con baselines de rendimiento
• owasp-asi-checker.py sin hallazgos criticos/altos

6.6 Template de tracking

Para registrar el estado de pre-alineacion SP 800-53, usar el template: project/F08_security/nist_ai_controls.yaml

Para registrar el estado por funcion AI RMF (Govern/Map/Measure/Manage), usar: project/F08_security/nist_rmf_functions.yaml

---

7. Modelo de Identidad del Framework vs. NIST

7.1 Como AGENTS.md implementa identidad NIST

AGENTS.md es el artefacto central de identidad de agentes. Implementa los conceptos NIST de la siguiente forma:

Concepto NIST	Seccion en AGENTS.md	Que define
Agent identifier (IA-4)	Nombre del agente (@architect)	Identificador unico dentro del proyecto
Capabilities metadata	Rol + descripcion del agente	Que puede hacer el agente
Limitations metadata	Boundaries: Never list	Que NO puede hacer el agente
Authorization scope	Boundaries: Ask First / Always	Permisos granulares por tipo de accion
Human oversight	7 Golden Principles (Principle 4)	El humano es responsable final

7.2 Como .fab-coordination.yaml implementa delegacion NIST

.fab-coordination.yaml gestiona la coordinacion multi-agente y mapea a conceptos de delegacion:

Concepto NIST	Campo en .fab-coordination.yaml	Funcion
Delegation chain	tasks[].assigned_to	Quien ejecuta cada subtarea
Scope limitation	tasks[].scope + budget	Limites de la delegacion
Non-transitivity	Sin permiso de sub-delegacion	Agentes no pueden delegar a otros
Revocation	status: cancelled + kill switch	Revocacion de delegacion
Accountability	tasks[].checkpoints	Puntos de verificacion trazables

7.3 Como settings.json implementa autorizacion NIST

settings.json es el artefacto de autorizacion que mapea directamente a AC (Access Control):

Concepto NIST	Campo en settings.json	Funcion
AC-3 (enforcement)	permissions.deny	Lista de operaciones prohibidas
AC-6 (minimo privilegio)	permissions.allow (explicit)	Solo lo permitido, nada mas
Session scope	Per-session permissions	Permisos no persisten entre sesiones
Tool-level access	allowed-tools en skills	Granularidad por herramienta

---

8. Nivel de Implementacion por Track

Track	Nivel NIST	Que implementar
Solo	Basico	AGENTS.md con boundaries, settings.json deny-by-default, git co-authorship, AIBOM
Lean	Medio	+ JIT tokens, Langfuse traces, dora-metrics.py, fab-kill-switch.sh, agent cards A2A
Full	Alto	+ NHI lifecycle completo, IdP integration, SIEM, audit dashboard, .fab-coordination.yaml, compliance automation

---

9. Patrones Practicos de Identidad para Agentes AI

Esta seccion cubre patrones de implementacion concretos para autenticacion, autorizacion e identidad de agentes AI, alineados con los estandares modernos OAuth 2.1, SPIFFE y los mecanismos de autenticacion MCP.

9.1 OAuth 2.1 para Autenticacion Agente-a-Servicio

OAuth 2.1 consolida las mejores practicas de OAuth 2.0 y es el estandar recomendado para autenticacion machine-to-machine (M2M) de agentes AI.

Client Credentials Grant (M2M)

El flujo client_credentials es el patron principal para agentes autonomos (FABs) que acceden a APIs y servicios sin intervencion humana:

Concepto	Implementacion en Framework
Client ID	Agent ID declarado en AGENTS.md (ej. fab-architect-001)
Client Secret	Gestionado via secrets manager (nunca en repo)
Scope	Permisos derivados de settings.json permissions + skill allowed-tools
Token lifetime	Corto (15-30 min), sin refresh tokens para M2M
Token rotation	Automatica via gateway — gateway_policy.yaml configura rotation policy

Flujo recomendado

1. El FAB solicita token al Authorization Server con client_credentials + scope limitado
2. El AS valida el client contra el registro de agentes (AGENTS.md como fuente de verdad)
3. El AS emite access token con claims: agent_id, roles, max_scope, delegation_chain
4. El FAB presenta el token al Resource Server (API, MCP server, servicio externo)
5. El Resource Server valida token + verifica scope contra la accion solicitada
6. Audit log registra: agent_id, accion, recurso, timestamp, delegation_chain

Configuracion en gateway_policy.yaml

# Ejemplo de configuracion OAuth 2.1 para agentes
agent_auth:
  protocol: "oauth2.1"
  grant_type: "client_credentials"
  token_endpoint: "https://auth.example.com/oauth/token"
  token_lifetime_seconds: 900  # 15 minutos
  token_rotation: true
  scopes:
    fab-architect: ["read:code", "write:design", "read:tests"]
    fab-qa-engineer: ["read:code", "write:tests", "execute:tests"]
    fab-security-reviewer: ["read:code", "read:security", "write:findings"]
  require_pkce: true  # OAuth 2.1 requiere PKCE
  disallow_implicit: true  # OAuth 2.1 prohibe implicit grant

9.2 SPIFFE/SPIRE para Identidad de Workloads Containerizados

SPIFFE (Secure Production Identity Framework for Everyone) proporciona identidad criptografica a workloads sin depender de secrets estaticos. Es ideal para FABs ejecutandose en contenedores o Kubernetes.

Conceptos clave

Concepto SPIFFE	Aplicacion a FABs
SPIFFE ID	URI unica por agente: spiffe://org.example/fab/architect/instance-001
SVID (SPIFFE Verifiable Identity Document)	Certificado X.509 o JWT emitido por SPIRE
Workload Registration	Cada FAB se registra con attestation (proceso, k8s pod, cloud metadata)
Trust Domain	Boundary organizacional: spiffe://org.example
Federation	Permite agentes de diferentes trust domains comunicarse

Mapping a artefactos del framework

Artefacto Framework	Funcion SPIFFE
AGENTS.md	Registro de SPIFFE IDs autorizados por agente
.fab-coordination.yaml	Mapping agent_id → SPIFFE ID para cada instancia activa
gateway_policy.yaml	Politicas de acceso basadas en SPIFFE ID (allowlist)
settings.json	Permisos locales; SPIFFE gestiona identidad de red

Patron de implementacion para FABs en Kubernetes

1. SPIRE Server gestiona el trust domain del proyecto
2. SPIRE Agent corre como DaemonSet en cada nodo
3. Cada FAB (pod) recibe un SVID automaticamente via workload attestation
4. mTLS entre FABs usa SVIDs — zero trust sin secrets manuales
5. fab-coordinator.py valida SPIFFE IDs antes de asignar tareas
6. Rotacion de SVIDs es automatica (default: cada hora)

9.3 Patrones de Autenticacion MCP

Los servidores MCP (Model Context Protocol) requieren mecanismos de autenticacion especificos para verificar que los agentes que se conectan estan autorizados.

Modos de autenticacion MCP

Modo	Transporte	Autenticacion	Caso de uso
stdio (local)	stdin/stdout	Identidad de proceso (UID/PID)	FAB local, desarrollo
HTTP+SSE (remoto)	HTTPS	OAuth 2.1 Bearer token	FAB remoto, produccion
HTTP+Streamable (remoto)	HTTPS	OAuth 2.1 + mTLS (SPIFFE)	Multi-agente, enterprise

Configuracion de seguridad MCP en el framework

El artefacto project/F08_security/mcp_security_policy.yaml define la politica de autenticacion para MCP servers:

# Ejemplo de politica de autenticacion MCP
mcp_authentication:
  local_servers:
    transport: "stdio"
    auth_method: "process_identity"
    allowed_callers:
      - agent_id: "@architect"
        process_name: "claude"
      - agent_id: "@qa_engineer"
        process_name: "claude"
  remote_servers:
    transport: "https_sse"
    auth_method: "oauth2_bearer"
    token_source: "agent_credential_store"
    require_tls: true
    min_tls_version: "1.3"
    certificate_validation: "strict"
  tool_annotations:
    enforce: true  # Respetar readOnlyHint, destructiveHint, etc.
    block_destructive_without_approval: true

9.4 Implementacion en el Framework: Artefactos como Infraestructura de Identidad

El framework utiliza artefactos declarativos como infraestructura de identidad. Cada artefacto cumple un rol especifico:

AGENTS.md como Registro de Identidad de Agentes

AGENTS.md es la fuente de verdad para identidades de agentes. Mapea a conceptos de Identity Provider (IdP):

Funcion IdP	Implementacion en AGENTS.md
User registry	Seccion por agente con nombre unico (@architect, @qa_engineer)
Profile/claims	Rol, capabilities, description de cada agente
Scope definitions	Boundaries: Never (prohibido), Ask First (requiere aprobacion), Always (permitido)
Role assignment	7 Golden Principles definen el modelo de responsabilidad
Lifecycle	Agentes se agregan/remueven del archivo; git history como audit trail

settings.json como Politica de Autorizacion

settings.json funciona como un Policy Decision Point (PDP) declarativo:

Funcion PDP	Implementacion en settings.json
Default policy	deny-by-default — todo lo no permitido esta prohibido
Allow rules	permissions.allow lista operaciones permitidas
Deny rules	permissions.deny lista operaciones explicitamente prohibidas
Scope per tool	Skills con allowed-tools en frontmatter limitan herramientas por contexto
Session isolation	Permisos no persisten entre sesiones (zero-trust session model)

.fab-coordination.yaml como Cadena de Delegacion

.fab-coordination.yaml implementa el modelo de delegacion y actua como registro de cadenas de autorizacion:

Funcion de delegacion	Implementacion en .fab-coordination.yaml
Delegation grant	tasks[].assigned_to — que agente recibe la delegacion
Scope limitation	tasks[].scope + budget — limites de la delegacion
Chain of custody	tasks[].delegated_by — quien autorizo la delegacion
Non-transitivity	Agentes no pueden sub-delegar (enforced por fab-coordinator.py)
Temporal bounds	tasks[].deadline + tasks[].started_at — ventana temporal
Revocation	status: cancelled + kill switch signal

gateway_policy.yaml como Punto de Enforcement

gateway_policy.yaml es el Policy Enforcement Point (PEP) donde se aplican todas las decisiones:

Funcion PEP	Implementacion en gateway_policy.yaml
Request validation	Rate limiting, allowed models, request size limits
Token verification	Validacion de OAuth 2.1 tokens o SPIFFE SVIDs
Scope enforcement	Verificar que el scope del token cubre la accion solicitada
Audit logging	Registrar cada decision (allow/deny) con context completo
Circuit breaker	Integracion con fab-cost-guard.py para limites de costo

9.5 Patron de Logging de Cadenas de Delegacion

Para cumplir con NIST AU (Audit & Accountability), cada delegacion debe ser trazable. El patron de logging registra quien autorizo a que agente para hacer que accion.

Estructura del log de delegacion

Cada entrada en el log de delegacion contiene:

Campo	Tipo	Descripcion
timestamp	ISO 8601	Momento de la delegacion
delegation_id	UUID	Identificador unico de la delegacion
delegator	string	Quien autoriza (humano o agente superior)
delegate	string	Agente que recibe la delegacion
action	string	Accion autorizada (ej. “write:code”, “execute:tests”)
scope	object	Limites: archivos, directorios, budget, tiempo
justification	string	Razon de la delegacion (intent_id, task description)
chain	list	Cadena completa de delegaciones previas
expiry	ISO 8601	Cuando expira la delegacion
revoked	boolean	Si la delegacion fue revocada
revocation_reason	string	Motivo de revocacion (si aplica)

Ejemplo de log

# Ejemplo de entrada en el log de delegacion
delegation_log:
  - delegation_id: "del-20260325-001"
    timestamp: "2026-03-25T10:30:00Z"
    delegator: "human:lead-engineer"
    delegate: "fab:architect-001"
    action: "execute:f03-f05"
    scope:
      directories: ["src/", "project/F03_knowledge/", "project/F04_architecture/"]
      budget_usd: 5.00
      max_duration_minutes: 120
    justification: "intent-2026-0325-api-redesign"
    chain:
      - "human:lead-engineer → fab:architect-001"
    expiry: "2026-03-25T12:30:00Z"
    revoked: false

  - delegation_id: "del-20260325-002"
    timestamp: "2026-03-25T10:35:00Z"
    delegator: "fab:architect-001"
    delegate: "fab:qa-engineer-001"
    action: "execute:write-tests"
    scope:
      directories: ["tests/"]
      budget_usd: 2.00
      max_duration_minutes: 60
    justification: "subtask de del-20260325-001"
    chain:
      - "human:lead-engineer → fab:architect-001"
      - "fab:architect-001 → fab:qa-engineer-001"
    expiry: "2026-03-25T11:35:00Z"
    revoked: false

Donde se implementa en el framework

Componente	Rol en el logging de delegacion
fab-coordinator.py	Genera entradas de delegacion al asignar tareas
.fab-coordination.yaml	Almacena estado actual de delegaciones activas
progress-tracker.md	Registro legible de delegaciones y sus resultados
dora-metrics.py	Analiza delegation logs para metricas de AI attribution
fab-kill-switch.sh	Revoca delegaciones y registra revocacion en el log

9.6 Template de Configuracion de Identidad

Ejemplo completo de configuracion de identidad para un proyecto que usa los tres patrones:

project/F08_security/agent_identity_config.yaml

# Configuracion de identidad de agentes AI
# Referencia: NIST_Agent_Identity_Guide.md seccion 9

agent_identity:
  version: "1.0.0"
  trust_domain: "spiffe://myorg.example"

  # --- Registro de agentes autorizados ---
  agents:
    - agent_id: "@architect"
      spiffe_id: "spiffe://myorg.example/fab/architect"
      oauth_client_id: "fab-architect-001"
      roles: ["design", "review"]
      max_scope: ["read:code", "write:design", "read:tests"]

    - agent_id: "@qa_engineer"
      spiffe_id: "spiffe://myorg.example/fab/qa-engineer"
      oauth_client_id: "fab-qa-001"
      roles: ["test", "validate"]
      max_scope: ["read:code", "write:tests", "execute:tests"]

    - agent_id: "@security_reviewer"
      spiffe_id: "spiffe://myorg.example/fab/security"
      oauth_client_id: "fab-security-001"
      roles: ["audit", "scan"]
      max_scope: ["read:code", "read:security", "write:findings"]

  # --- Politica de autenticacion ---
  authentication:
    primary: "oauth2.1"
    fallback: "spiffe_mtls"
    token_lifetime_seconds: 900
    require_pkce: true
    mcp_auth:
      local: "process_identity"
      remote: "oauth2_bearer"

  # --- Politica de delegacion ---
  delegation:
    max_chain_depth: 3  # maximo 3 niveles de delegacion
    require_justification: true
    log_all_delegations: true
    log_destination: "delegation_audit.log"
    auto_revoke_on_expiry: true

  # --- Monitoreo ---
  monitoring:
    log_format: "structured_json"
    alert_on_denied_access: true
    alert_on_chain_depth_exceeded: true
    audit_retention_days: 365

---

10. NIST AI Agent Standards Initiative (Febrero 2026)

10.1 Que es la AI Agent Standards Initiative

En febrero de 2026, NIST anuncio la AI Agent Standards Initiative, un esfuerzo del National Cybersecurity Center of Excellence (NCCoE) para desarrollar estandares de interoperabilidad y seguridad para agentes AI. La iniciativa incluye un concept paper enfocado en identidad y autorizacion de agentes, con el objetivo de habilitar ecosistemas de agentes AI seguros y verificables.

10.2 Alcance de la iniciativa

Area	Descripcion	Estado (marzo 2026)
Identidad de agentes	Esquemas estandarizados para identificar agentes AI de forma unica y verificable	Concept paper publicado
Autorizacion y delegacion	Modelos de permisos para agentes que actuan en nombre de usuarios u otros agentes	En desarrollo
Interoperabilidad	Protocolos estandar para comunicacion agente-a-agente (A2A) y agente-a-servicio	En desarrollo
Cadenas de confianza	Mecanismos para establecer y verificar cadenas de delegacion entre agentes	Propuesto
Accountability	Requisitos de audit trail y atribucion de acciones a agentes especificos	Propuesto

10.3 NCCoE Concept Paper: Agent Identity & Authorization

El concept paper del NCCoE establece requisitos anticipados para sistemas multi-agente:

1. Identificadores unicos: cada agente debe tener un identificador unico, verificable y no reutilizable
2. Metadata de capacidades: los agentes deben declarar sus capacidades y limitaciones de forma legible por maquina
3. Autorizacion granular: permisos por accion, recurso y contexto temporal
4. Delegacion verificable: cadenas de delegacion trazables con limites de profundidad y revocacion
5. Minimo privilegio: deny-by-default con escalamiento explicito

10.4 Pre-alineacion del framework

El framework Baseline ya implementa los conceptos clave de la iniciativa a traves de artefactos declarativos existentes:

Requisito NIST Agent Standards	Artefacto del Framework	Como se alinea
Identificador unico de agente	AGENTS.md	Cada agente tiene nombre unico (@architect, @qa_engineer) con rol y capabilities
Registro de identidades	AGENTS.md + .fab-coordination.yaml	Registro centralizado de agentes activos con agent_id unico
Metadata de capacidades	.claude/agents/*.md + AGENTS.md	Rol, description, boundaries (Never/Ask First/Always)
Credential management	gateway_policy.yaml + OAuth 2.1 config	Token lifecycle, rotation, PKCE (seccion 9.1 de esta guia)
Modelo de permisos	settings.json	permissions.deny/permissions.allow, deny-by-default
Cadenas de delegacion	.fab-coordination.yaml + fab-coordinator.py	tasks[].assigned_to, delegated_by, scope limitation
Minimo privilegio	settings.json + skills allowed-tools	Deny-by-default, permisos explicitos por herramienta y contexto
Audit trail	dora-metrics.py + git co-authorship + Langfuse	Trazabilidad completa de acciones por agente
Action logging	progress-tracker.md + checkpoints	Registro de cada accion con timestamp y resultado
Atribucion	Git co-authorship + fab-eval-builders.py	AI attribution en commits y metricas DORA
Soporte A2A	Agent cards (A2A protocol)	Identidad y capabilities expuestas via protocolo estandar
Soporte MCP	mcp_config.json + MCP security audit	Servidores MCP auditados con auth y transport security
Protocolos estandar	OAuth 2.1, SPIFFE, MCP auth	Patrones de autenticacion documentados (seccion 9)

10.5 Tracking de pre-alineacion

Para registrar el estado de pre-alineacion con los estandares anticipados de NIST Agent Standards, usar el template: project/F08_security/nist_agent_standards.yaml

Este template cubre las cuatro areas principales: identity, authorization, accountability e interoperability.

10.6 Acciones para cuando el estandar se finalice

Cuando NIST publique el estandar final (estimado Q4 2026 - Q1 2027), los equipos deben:

1. Revisar el gap analysis: comparar el template nist_agent_standards.yaml contra los requisitos finales y actualizar el campo status de cada control
2. Actualizar AGENTS.md: verificar que el formato de identidad de agentes cumple con el esquema estandarizado de NIST (agregar campos si es necesario)
3. Validar settings.json: confirmar que el modelo de permisos cumple con los requisitos de autorizacion granular del estandar
4. Auditar cadenas de delegacion: verificar que .fab-coordination.yaml y fab-coordinator.py cumplen con los requisitos de delegation chains verificables
5. Actualizar compliance-linter.py: agregar reglas de validacion automatizada para los nuevos requisitos
6. Generar evidencia formal: ejecutar compliance-linter.py, dora-metrics.py y mcp-security-audit.py para generar reportes de alineacion
7. Actualizar esta guia: incorporar el mapping definitivo y reemplazar las referencias a “anticipado” con los requisitos finales

---

11. Referencias

• NIST AI RMF 1.0 (enero 2023)
• NIST AI 600-1: Generative AI Profile (julio 2024)
• NIST SP 800-53 Rev. 5 (septiembre 2020, actualizado diciembre 2024)
• NIST RFI: AI Agent Identity and Access Management (marzo 2026)
• OAuth 2.1 (RFC 9728 — draft consolidado de OAuth 2.0 best practices)
• SPIFFE Specification v1.0 (spiffe.io)
• SPIRE Documentation (spiffe.io/docs/latest/spire-about/)
• MCP Specification — Authentication & Transport (modelcontextprotocol.io)
• Compliance & Regulatory Alignment Guide (framework/guides/)
• A2A Protocol Integration Guide (framework/guides/)
• OWASP Agentic Security Guide (consolidada en Compliance Guide)
• NIST AI RMF Functions Template (project-template/project/F08_security/nist_rmf_functions.yaml)
• NIST AI Agent Standards Initiative — NCCoE Concept Paper (febrero 2026)
• NIST Agent Standards Pre-Alignment Template (project-template/project/F08_security/nist_agent_standards.yaml)
• ISO 42001 Alignment Guide (framework/guides/)

---

Guia de referencia del AI-First Engineering Framework v7.6.0 — Identidad de agentes NIST, AI RMF functions mapping, SP 800-53 mapping, patrones OAuth 2.1/SPIFFE/MCP, pre-alineacion COSAiS y NIST AI Agent Standards Initiative.