Amazon Bedrock customers can now attribute model inference usage to specific teams, applications, environments, and experiments at the individual request level on the InvokeModel and InvokeModelWithResponseStream APIs. This gives customers fine-grained visibility into how their Amazon Bedrock usage is distributed across their organization, helping them understand consumption patterns, optimize spend, and report usage back to internal stakeholders without provisioning additional resources.
This launch builds on Amazon Bedrock’s existing portfolio of usage attribution capabilities. Customers can already attribute model inference usage at the resource and identity level using application inference profiles, IAM principal-based attribution, project-level tracking on the OpenAI-compatible bedrock-mantle endpoint, and workspace-level tracking for Anthropic Claude models. For finer-grained, per-request attribution, the Converse and ConverseStream APIs have supported request-level metadata since launch. Today’s release brings the same capability to the InvokeModel and InvokeModelWithResponseStream APIs, giving customers a consistent way to tag inference calls across the entire bedrock-runtime endpoint.
With this launch, customers can tag each Amazon Bedrock model inference call with attributes like team, project, or environment, and analyze usage by these tags in Amazon Bedrock model invocation logs. To get started, enable model invocation logging in the AWS Region where you call Amazon Bedrock, then add metadata to your inference requests. This feature is available in all AWS commercial Regions where Amazon Bedrock is available. To learn more, see Request metadata.
Amazon Bedrock customers can now attribute model inference usage to specific teams, applications, environments, and experiments at the individual request level on the InvokeModel and InvokeModelWithResponseStream APIs. This gives customers fine-grained visibility into how their Amazon Bedrock usage is distributed across their organization, helping them understand consumption patterns, optimize spend, and report usage back to internal stakeholders without provisioning additional resources. This launch builds on Amazon Bedrock’s existing portfolio of usage attribution capabilities. Customers can already attribute model inference usage at the resource and identity level using application inference profiles, IAM principal-based attribution, project-level tracking on the OpenAI-compatible bedrock-mantle endpoint, and workspace-level tracking for Anthropic Claude models. For finer-grained, per-request attribution, the Converse and ConverseStream APIs have supported request-level metadata since launch. Today’s release brings the same capability to the InvokeModel and InvokeModelWithResponseStream APIs, giving customers a consistent way to tag inference calls across the entire bedrock-runtime endpoint. With this launch, customers can tag each Amazon Bedrock model inference call with attributes like team, project, or environment, and analyze usage by these tags in Amazon Bedrock model invocation logs. To get started, enable model invocation logging in the AWS Region where you call Amazon Bedrock, then add metadata to your inference requests. This feature is available in all AWS commercial Regions where Amazon Bedrock is available. To learn more, see Request metadata.
IA en el trabajo: Cuando los mayores usuarios del software no son humanos
Los agentes ya operan dentro de su stack, para cambiar lo que el software debe ser y en qué deben invertir los líderes.
Por: Jared Spataro, CMO de IA en el Trabajo de Microsoft.
Cada software con el que funciona su organización—su CRM, su ERP, su plataforma de gestión de proyectos, su suite de productividad—se construyó bajo una única suposición: que el usuario principal era un ser humano. Esa suposición ya no se cumple.
Los agentes ya trabajan dentro de su pila de software—a velocidad de máquina, sin necesidad de menús ni formación, para gestionar el trabajo en segundos o minutos que antes llevaban horas o días a los humanos. Ahora la pregunta es qué cambia eso —y para quién.
El usuario ha cambiado—y eso lo cambia todo
Durante 30 años, cada software empresarial se construyó en torno a una única limitación: el humano en el otro extremo. Cada característica tenía que ser descubrible. Cada flujo de trabajo tenía que ser aprendible. El límite de lo que el software podía hacer estaba limitado a lo que una persona podía navegar. Cuando los agentes hacen el trabajo, ese techo desaparece. El software ya no tiene que reflejar la elección entre lo potente y lo utilizable.
La evidencia de ese cambio ya está aquí. Un responsable financiero de uno de nuestros equipos de finanzas comerciales describió de manera reciente sentarse con un conjunto de datos desordenado, un cuaderno en blanco y un único objetivo: llegar a la historia del negocio más rápido. Pidieron a Copilot que construyera un pivote a nivel de producto a partir de una extracción de datos en bruto. Cuando la primera revisión volvió como vista anual, escribieron en inglés claro que necesitaban trimestres fiscales—y Copilot volvió a la fuente, añadió una columna que mapeaba cada fila al trimestre correcto y reconstruyó el pivote. El gerente insistió más, pidió una descomposición Volumen-Tasa-Total, además de un puente de contribución año tras año. Y al final, para poner a prueba el resultado, rompieron de manera deliberada varias fórmulas y pidieron a Copilot que auditara todo el cuaderno. Recorría todas las pestañas, marcaba cada inconsistencia con un nivel de gravedad y reescribía cada fórmula rota—todo mientras el encargado respondía correos y llamadas en una segunda pantalla. Su reflexión refleja el cambio: «Aunque funciona de manera discreta en segundo plano, podemos centrar nuestro enfoque en las ideas, la toma de decisiones y conversaciones significativas entre socios de negocio.» El gerente no navegaba por Excel. La IA lo hacía.
Eso de «estar en segundo plano en silencio» importa. Muchos de los agentes más importantes ni siquiera aparecen en una ventana de chat. Funcionarán sin cabeza—activados por un cambio de política, una actualización de datos, la apertura de un ticket, un envío retrasado—para ejecutar trabajo dentro de los sistemas a velocidad de máquina, y luego solo aparecen resultados cuando una persona necesite revisar, aprobar o intervenir.
Nuestro nuevo Copilot Cowork es un sistema agéntico que se integra en el software empresarial que su organización ya ejecuta y ejecuta el trabajo en su nombre: el humano establece el objetivo, el agente realiza el trabajo. Además, resulta ser un producto que fue escrito casi en su totalidad por agentes, por un puñado de ingenieros, en cuestión de semanas. En ambos casos, el cambio es el mismo: los agentes se convierten en los principales operadores del software empresarial.
El software se rediseña para agentes en tres capas
Los agentes ya trabajan dentro de sus herramientas. Las plataformas que avanzan se transformarán desde los datos hacia arriba.
Qué significa esto para el software que ya poseen
La mayor parte de la conversación sobre IA y software empresarial se centra en la superficie: la interfaz, las funciones, la velocidad. Y todo eso es importante, pero se han comenzado a producir cambios aún más importantes bajo el capó.
Experiencia de usuario. Existe una opinión que ha comenzado a ganar fuerza, de que las interfaces desaparecerán por completo a medida que los agentes tomen el control, pero la tecnología no se difunde así. La adopción ocurre cuando te encuentras con los usuarios donde están: en las herramientas que conocen y en los lienzos donde vive el trabajo. Las interfaces se convierten en el punto de encuentro: donde el trabajo se revisa, comparte y se entrega. Ahora hay dos clases de usuario: humano y agente, y el software tiene que servir a ambos.
Lógica de negocio. La capa que codifica cómo opera una empresa: cómo cierras los libros, cómo se aprueba un informe y a quién se escala el caso. Ahora mismo, esa lógica está integrada en flujos de trabajo diseñados para humanos. A medida que los agentes asumen más de esa ejecución, debe estar integrada en el sistema como habilidades que un agente pueda invocar de manera directa. De ahí vendrán las mayores ganancias de eficiencia.
Datos preparados. Cada aplicación empresarial almacena datos como base para su trabajo, pero los agentes se benefician de que estén optimizados para su uso. Los agentes pueden averiguar la estructura y el significado de un conjunto de datos por sí mismos, pero si tienen que hacerlo cada vez que alguien hace una pregunta, la IA tiene que reinventar la rueda una y otra vez. La solución es preparar los datos a medida que entran en el sistema para que los agentes puedan responder de manera directa a la pregunta en lugar de averiguar qué ven ustedes. Piénsenlo como la diferencia entre entregarle a alguien un montón enorme de papeles y un informe bien organizado. Misma información, punto de partida muy diferente.
Qué significa esto para su organización
Si los agentes gestionan más la ejecución y las barreras para crear software son más bajas que nunca, surge una pregunta razonable: ¿por qué no construir el suyo propio? Porque, aunque construir su propio CRM ahora pueda ser posible gracias a la IA, cada hora dedicada a construir y mantener software que una solución lista ya podría manejar, es una hora que no se dedica al trabajo que define su ventaja competitiva. La era de la IA va a obligar a hacer un ajuste de cuentas sobre dónde las organizaciones destinan su tiempo y recursos. Las empresas que avancen no serán las que más hagan; serán las que sean más disciplinadas en lo que solo ellas pueden hacer. Las Frontier Firms (Empresas Frontera) que vemos, no externalizan más, sino que se concentran más.
Esto también se aplica a las herramientas que su organización ya posee o a las que está suscrita la organización. La mayoría de las organizaciones pagan por software con funciones avanzadas que pocos o ningún empleado utiliza. Los agentes encontrarán y usarán esas funciones. Y de manera eventual, incluso podrían empezar a solicitar capacidades que ningún usuario humano habría imaginado. El software se desarrollará más rápido que cualquier individuo que pueda seguir, y eso hace que la capa humana sea más relevante, no menos.
A medida que el trabajo humano se traslada aguas arriba—menos tiempo práctico en el software, más tiempo para decidir qué debe producir—las organizaciones que avancen serán las que desarrollen de manera deliberada la capacidad de sus empleados para marcar dirección, evaluar resultados y mantener la responsabilidad de cómo funciona el sistema. Eso es una inversión de talento y cultura, no tecnológica. Y el momento de empezar a invertir es ahora.
Para más información sobre la IA y el futuro del trabajo, suscríbanse a este boletín.
Amazon SageMaker Unified Studio now supports data quality rule authoring and evaluation, powered by AWS Glue Data Quality. Data engineers, analysts, and data scientists can define data quality rules, run ruleset evaluations, and view results directly within SageMaker Unified Studio for both data at rest in catalog tables and data in transit within Visual ETL jobs. This helps you catch data quality issues before bad data enters your data lakes or affects downstream analytics and machine learning workloads.
With this launch, you can author rules using the same Data Quality Definition Language (DQDL) used in AWS Glue Data Quality and run evaluations directly in SageMaker Unified Studio across two workflows. For data at rest, a dedicated Data Quality tab on catalog assets provides rule authoring, on-demand or scheduled evaluations, and detailed per-rule pass/fail results. For data in transit, you can add an Evaluate Data Quality transform to any Visual ETL job, and review data quality results as part of the run details. You can create rulesets that check for completeness, uniqueness, freshness, accuracy, and other data quality dimensions.
This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available, in both AWS IAM Identity Center-based and IAM-based domains. To learn more, visit the Amazon SageMaker Unified Studio documentation.
Amazon SageMaker Unified Studio now supports data quality rule authoring and evaluation, powered by AWS Glue Data Quality. Data engineers, analysts, and data scientists can define data quality rules, run ruleset evaluations, and view results directly within SageMaker Unified Studio for both data at rest in catalog tables and data in transit within Visual ETL jobs. This helps you catch data quality issues before bad data enters your data lakes or affects downstream analytics and machine learning workloads. With this launch, you can author rules using the same Data Quality Definition Language (DQDL) used in AWS Glue Data Quality and run evaluations directly in SageMaker Unified Studio across two workflows. For data at rest, a dedicated Data Quality tab on catalog assets provides rule authoring, on-demand or scheduled evaluations, and detailed per-rule pass/fail results. For data in transit, you can add an Evaluate Data Quality transform to any Visual ETL job, and review data quality results as part of the run details. You can create rulesets that check for completeness, uniqueness, freshness, accuracy, and other data quality dimensions. This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available, in both AWS IAM Identity Center-based and IAM-based domains. To learn more, visit the Amazon SageMaker Unified Studio documentation.
Today, AWS Security Hub brings identity risk into the same unified console where central security teams already manage threats, exposures, and posture findings. Security Hub now detects unused IAM permissions, roles, and credentials across your AWS organization, helping central security teams identify and reduce identity risk at scale. Until now, managing identity risk across hundreds of accounts required toggling between multiple tools, with no unified view connecting unused permissions to actual resource exposure. Security Hub now surfaces these identity risks alongside threats, exposures, and posture findings in a unified console, enabling teams to prioritize remediation based on actual organizational risk.
When you enable Security Hub for your organization, a service-linked IAM Access Analyzer is automatically created in each member account with no additional configuration required. Security Hub evaluates IAM principals against 90 days of actual access activity, detects unused access, and correlates identity findings with exposure context so teams can focus on the risks that matter most. Security Hub also provides on-demand generation of recommended least-privilege policies based on actual usage patterns, helping teams refine IAM permissions and reduce their attack surface. These capabilities represent a foundational step toward broader cloud infrastructure entitlement management in Security Hub, delivered with consistent workflows, automation rules, and downstream integrations. These capabilities are included with Security Hub Essentials at no additional cost.
Today, AWS Security Hub brings identity risk into the same unified console where central security teams already manage threats, exposures, and posture findings. Security Hub now detects unused IAM permissions, roles, and credentials across your AWS organization, helping central security teams identify and reduce identity risk at scale. Until now, managing identity risk across hundreds of accounts required toggling between multiple tools, with no unified view connecting unused permissions to actual resource exposure. Security Hub now surfaces these identity risks alongside threats, exposures, and posture findings in a unified console, enabling teams to prioritize remediation based on actual organizational risk. When you enable Security Hub for your organization, a service-linked IAM Access Analyzer is automatically created in each member account with no additional configuration required. Security Hub evaluates IAM principals against 90 days of actual access activity, detects unused access, and correlates identity findings with exposure context so teams can focus on the risks that matter most. Security Hub also provides on-demand generation of recommended least-privilege policies based on actual usage patterns, helping teams refine IAM permissions and reduce their attack surface. These capabilities represent a foundational step toward broader cloud infrastructure entitlement management in Security Hub, delivered with consistent workflows, automation rules, and downstream integrations. These capabilities are included with Security Hub Essentials at no additional cost. To learn more, see Understanding unused access findings in Security Hub in the AWS Security Hub User Guide and the AWS Security Hub product page. For the full list of AWS Regions where Security Hub is available, see the AWS Regional Services List.
Amazon Elastic Container Service (ECS) now supports mounting Amazon Elastic Block Store (EBS) volumes to containers in the AWS GovCloud Regions. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media transcoding, and ML inference workloads using serverless containers. With EBS task attachment, customers can allow ECS to provision, manage and de-provision EBS Volumes with each new ECS Task launch. EBS task attachment will automatically wire these volumes to their containerized workloads. Customers can have ECS format an empty volume on their behalf or bring an EBS snapshot for ECS to use to create new volumes. EBS task attachment is now available in the AWS GovCloud Regions for EC2, Fargate, and Managed Instances launch types. To learn more, see Use Amazon EBS volumes with Amazon ECS in the Amazon ECS Developer Guide.
Amazon Elastic Container Service (ECS) now supports mounting Amazon Elastic Block Store (EBS) volumes to containers in the AWS GovCloud Regions. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media transcoding, and ML inference workloads using serverless containers. With EBS task attachment, customers can allow ECS to provision, manage and de-provision EBS Volumes with each new ECS Task launch. EBS task attachment will automatically wire these volumes to their containerized workloads. Customers can have ECS format an empty volume on their behalf or bring an EBS snapshot for ECS to use to create new volumes. EBS task attachment is now available in the AWS GovCloud Regions for EC2, Fargate, and Managed Instances launch types. To learn more, see Use Amazon EBS volumes with Amazon ECS in the Amazon ECS Developer Guide.
AWS Security Hub Extended plan now includes 21 curated partner solutions across 9 security categories, adding SentinelOne (endpoint), CyberArk (identity), Sublime (email), Varonis (data security), LayerX (browser), Native Security (cloud), and Zenity (AI security). With these additions, you have more flexibility to select the solutions that best fit your enterprise security requirements. All solutions have published pay-as-you-go pricing, a single AWS bill, automatic Enterprise Discount Program (EDP) eligibility, unified Level 1 support for AWS Enterprise Support customers, and no long-term commitments.
Security Hub Extended is a plan of Security Hub that helps simplify how you procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. With today’s expansion, you now have more choice within each category, selecting between established leaders and fast-growing innovators across your security domains. Security findings from all participating solutions are emitted in the Open Cybersecurity Schema Framework (OCSF) schema and automatically aggregated in AWS Security Hub. With the Extended plan, you can combine AWS and curated partner solutions to quickly identify and respond to risks that span boundaries.
We will continue to expand the Extended plan based on customer feedback. The seven new curated partner solutions are available today in all AWS commercial Regions where Security Hub is available. For a list of supported Regions, see the AWS Region table. For more information about pricing, visit the AWS Security Hub pricing page. To get started, visit the AWS Security Hub console or product page.
AWS Security Hub Extended plan now includes 21 curated partner solutions across 9 security categories, adding SentinelOne (endpoint), CyberArk (identity), Sublime (email), Varonis (data security), LayerX (browser), Native Security (cloud), and Zenity (AI security). With these additions, you have more flexibility to select the solutions that best fit your enterprise security requirements. All solutions have published pay-as-you-go pricing, a single AWS bill, automatic Enterprise Discount Program (EDP) eligibility, unified Level 1 support for AWS Enterprise Support customers, and no long-term commitments.
Security Hub Extended is a plan of Security Hub that helps simplify how you procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. With today’s expansion, you now have more choice within each category, selecting between established leaders and fast-growing innovators across your security domains. Security findings from all participating solutions are emitted in the Open Cybersecurity Schema Framework (OCSF) schema and automatically aggregated in AWS Security Hub. With the Extended plan, you can combine AWS and curated partner solutions to quickly identify and respond to risks that span boundaries.
We will continue to expand the Extended plan based on customer feedback. The seven new curated partner solutions are available today in all AWS commercial Regions where Security Hub is available. For a list of supported Regions, see the AWS Region table. For more information about pricing, visit the AWS Security Hub pricing page. To get started, visit the AWS Security Hub console or product page.
Today, Amazon Web Services (AWS) announced version 0.1 of ExtendDB, an open source project that implements the Amazon DynamoDB API with pluggable storage backends. Amazon DynamoDB is a serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. ExtendDB enables application developers, platform teams, and enterprise architects to use the DynamoDB programming model in environments where the DynamoDB managed service is not available, including developer laptops, on-premises data centers, and disconnected edge sites, without rewriting application code.
ExtendDB implements the DynamoDB control plane and data plane APIs, including operations on tables, items, and streams. The reference storage backend at launch is PostgreSQL, and the pluggable architecture allows the community to add new storage backends without modifying the core adapter. Developers can use ExtendDB for high-fidelity local development and continuous integration testing, and operate DynamoDB-shaped workloads in on-premises data centers backed by a supported database.
ExtendDB is maintained by AWS, released under the Apache 2.0 license, and developed in the open on GitHub. We invite the community to contribute backend implementations, submit feedback, and participate in the project’s evolution. To learn more, see the ExtendDB project page and the AWS database blog post. To get started or contribute, visit the GitHub repository.
Today, Amazon Web Services (AWS) announced version 0.1 of ExtendDB, an open source project that implements the Amazon DynamoDB API with pluggable storage backends. Amazon DynamoDB is a serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. ExtendDB enables application developers, platform teams, and enterprise architects to use the DynamoDB programming model in environments where the DynamoDB managed service is not available, including developer laptops, on-premises data centers, and disconnected edge sites, without rewriting application code. ExtendDB implements the DynamoDB control plane and data plane APIs, including operations on tables, items, and streams. The reference storage backend at launch is PostgreSQL, and the pluggable architecture allows the community to add new storage backends without modifying the core adapter. Developers can use ExtendDB for high-fidelity local development and continuous integration testing, and operate DynamoDB-shaped workloads in on-premises data centers backed by a supported database. ExtendDB is maintained by AWS, released under the Apache 2.0 license, and developed in the open on GitHub. We invite the community to contribute backend implementations, submit feedback, and participate in the project’s evolution. To learn more, see the ExtendDB project page and the AWS database blog post. To get started or contribute, visit the GitHub repository.
AWS Billing Conductor Console now enables you to see which accounts have received or accepted billing transfer invites but still lack access to pro forma billing data.
This page helps customers detect and close gaps in their account’s billing visibility. When an account accepts a billing transfer invitation, billing data is transferred to the inviting account. By configuring a billing group via AWS Billing Conductor, accounts can access pro forma cost data across Billing and Cost Management tools. This page provides visibility into what accounts currently lack access to pro forma billing data, making it easier to complete this configuration step. Customers can also sign up for daily notifications via AWS User Notifications and Amazon EventBridge to receive a summary of accepted billing transfers that lack a corresponding billing group. Notifications are available via email, Amazon Q Developer in chat applications (Slack, Microsoft Teams, and Amazon Chime), AWS Console Mobile Application push notifications, and the Console Notifications Center.
AWS Billing Conductor Console now enables you to see which accounts have received or accepted billing transfer invites but still lack access to pro forma billing data.
This page helps customers detect and close gaps in their account’s billing visibility. When an account accepts a billing transfer invitation, billing data is transferred to the inviting account. By configuring a billing group via AWS Billing Conductor, accounts can access pro forma cost data across Billing and Cost Management tools. This page provides visibility into what accounts currently lack access to pro forma billing data, making it easier to complete this configuration step. Customers can also sign up for daily notifications via AWS User Notifications and Amazon EventBridge to receive a summary of accepted billing transfers that lack a corresponding billing group. Notifications are available via email, Amazon Q Developer in chat applications (Slack, Microsoft Teams, and Amazon Chime), AWS Console Mobile Application push notifications, and the Console Notifications Center.
These features are available in the US East (N. Virginia) region. To get started, visit the AWS Billing Conductor console. To learn more about setting up EventBridge integration, see the EventBridge documentation. For instructions on configuring User Notifications, see the User Notifications documentation. To learn more about Billing Transfer and AWS Billing Conductor visit the Billing Transfer product page, AWS Billing documentation and the AWS Cost Management documentation.
Presentamos RAMPART y Clarity: Herramientas de código abierto para incorporar seguridad al flujo de trabajo de desarrollo de Agentes
Por: Ram Shankar Siva Kumar, Data Cowboy, AI Red Team.
Los sistemas de IA que se implementan hoy en las empresas son, de manera fundamental, diferentes de los que construíamos hace incluso dos años, porque han ido mucho más allá de responder preguntas y ahora acceden a su correo electrónico, recuperan registros de su CRM, llevan a cabo escritura y ejecución de código, y realizan acciones en su nombre a través de decenas de sistemas conectados. Ese cambio de «generar texto» a «hacer cosas en el mundo» cambia por completo la ecuación de seguridad, porque un agente que puede actuar, también puede actuar de manera potencial de formas que nadie pretendía.
Hoy, Microsoft abre el código de dos herramientas diseñadas para ayudar a los ingenieros: Microsoft RAMPART, un marco de pruebas de agentes para codificar escenarios adversariales y benignos como pruebas repetibles que pueden ejecutarse en CI, lo que facilita convertir hallazgos de equipos rojos e incidentes de IA en cobertura de regresión duradera; y Clarity, una caja de resonancia estructurada que ayuda a los equipos a determinar si construyen lo correcto antes de escribir una sola línea de código.
Hemos creado estas herramientas porque creemos que la seguridad en IA debe convertirse en una disciplina de ingeniería continua y no en un punto de control periódico, y creemos que la mejor manera de lograrlo es poner herramientas prácticas y abiertas en manos de quienes construyen la construcción.
Por qué invertimos en esto
Ayudar a los equipos a pensar en el «por qué» antes que en el «cómo» de la construcción de software: En la era de la programación de vibración, la ejecución es fácil y la pregunta más difícil es el «por qué». Los fallos de seguridad más caros que vemos casi siempre se remontan a errores de diseño que nadie cuestionó con prontitud, mucho antes de que se involucrara cualquier adversario — por ejemplo, cuando un equipo de producto decidió que su agente debía tener acceso a una herramienta, o manejar un flujo de usuario concreto, sin analizar por completo qué podría salir mal. Cuando surge el problema en un equipo rojo, el sistema ya está en gran parte construido, y abordarlo implica volver a empezar. Queríamos ofrecer a los responsables de producto e ingenieros una forma de poner a prueba sus suposiciones al inicio de un proyecto, cuando cambiar de rumbo es barato y la conversación adecuada puede ahorrar meses de retrabajo.
Ampliar las lecciones del red teaming en toda la industria. Las técnicas que descubren vulnerabilidades en un producto agente casi siempre arrojan luz sobre otro. Un ataque de inyección cruzada que funciona contra un sistema suele funcionar, con pequeñas variaciones, contra un agente de atención al cliente o un asistente de codificación. Pero esas lecciones tienden a quedarse encerradas en los informes individuales de interacción. Nuestro objetivo era construir un sistema donde las lecciones de los ejercicios de red teaming pudieran convertirse en activos de ingeniería ejecutables.
Hacer que los incidentes sean reproducibles y las mitigaciones verificables. Si algo falla en los sistemas de IA de producción, el equipo que responde debe hacer dos cosas con rapidez: replicar el incidente para entender justo qué ha pasado y verificar que la solución que envíen en verdad resiste las variantes del ataque original. Ambas tareas son más difíciles de lo que parecen con sistemas basados en LLMs probabilísticos, y la mayoría de los equipos acaban haciéndolas de manera manual de forma puntual. Queríamos herramientas diseñadas en específico para este flujo de trabajo, para que la respuesta a incidentes se convirtiera en un proceso de ingeniería repetible en lugar de un proceso de improvisación.
RAMPART: Pruebas de seguridad continuas para IA agéntica
RAMPART es un marco de trabajo de pruebas de código abierto que incorpora las técnicas de red teaming directo al flujo de trabajo de desarrollo. Está construido sobre PyRIT, el marco de automatización abierta de Microsoft para agrupar sistemas de IA generativa en red team, de modo que RAMPART aproveche las mejores pruebas adversariales de su clase, listas para usar. Mientras que PyRIT está optimizado para el descubrimiento de cajas negras por parte de los investigadores de seguridad tras la construcción del sistema, RAMPART se desarrolla para los ingenieros mientras se construye el sistema.
La experiencia de desarrollador resultará familiar para cualquiera que haya escrito pruebas de integración. Los equipos escriben pruebas pytest estándar que describen escenarios derivados de su modelo de amenazas. Cada prueba se conecta al agente a través de un adaptador delgado, orquesta una interacción y evalúa los resultados observables. Las pruebas demuestran una señal clara de aprobado o suspenso y pueden ser bloqueadas en CI igual que cualquier otra prueba de integración. Cuando se añade una nueva herramienta o fuente de datos al agente, la prueba de seguridad correspondiente puede añadirse en la misma pull request.
RAMPART se diferencia de las pruebas convencionales en los siguientes aspectos:
Diseñado para ataques de inyección rápida: la cobertura más madura de RAMPART hoy se centra en ataques de inyección cruzada, escenarios en los que un agente recupera o procesa contenido que podría estar envenenado de documentos, correos electrónicos, tickets u otras fuentes de datos que manipulan su comportamiento de forma indirecta. Se pueden añadir nuevas categorías de amenaza de manera incremental a medida que evolucionan los patrones de ataque, y los puntos de extensión del framework se definen todos como protocolos Python, por lo que la integración sigue ligera incluso para arquitecturas de agentes complejas.
Diseñado para comportamiento probabilístico: Dado que el comportamiento de los LLM es probabilístico, RAMPART soporta ensayos estadísticos. La misma prueba puede ejecutarse varias veces con políticas como «esta acción debe ser segura en al menos el 80 por ciento de las ejecuciones.» Esto refleja cómo se comportan en realidad los agentes en producción con mucha más precisión que la validación de un solo disparo.
Diseñado para reproducir tus hallazgos de equipos rojos de IA e incidentes de IA: RAMPART está diseñado para funcionar junto con equipos rojos (red teams) dedicados, y ambos se refuerzan de manera mutua. Los resultados de un compromiso con un equipo rojo pueden codificarse como pruebas RAMPART, lo que significa que el problema queda cubierto de manera permanente, se ejecuta en cada cambio y nunca retrocede de manera silenciosa. El modelo de propiedad se invierte de manera intencionada respecto al enfoque tradicional: los ingenieros escriben las pruebas, los ingenieros las ejecutan y los ingenieros tratan los fallos como cualquier otro error. El marco proporciona las estrategias de ataque, la generación adversarial de carga útil y la lógica de evaluación. El autor de la prueba se centra en expresar expectativas sobre lo que su agente debe y no debe hacer.
La seguridad del agente depende en última instancia de lo que haga el agente, lo que significa que los evaluadores deben analizar qué herramientas invoca, qué efectos secundarios ocurren y si esas acciones se mantienen dentro de los límites esperados. Los evaluadores de RAMPART están diseñados para inspeccionar todo eso. Son componibles, por lo que los equipos pueden combinarlas con lógica booleana para expresar condiciones de seguridad matizadas en lugar de depender de una sola señal binaria.
Clarity: Ayudar a comprobar las suposiciones de ingeniería de software
Mientras que la mayoría de las herramientas de IA están diseñadas para ayudar a los equipos a ejecutar más rápido, Clarity fue diseñada por Microsoft para ayudarles a determinar si ejecutan lo correcto desde el principio. Plantea el tipo de preguntas que harían arquitectos, gestores de producto e ingenieros de seguridad con experiencia, las que son fáciles de saltarse cuando un equipo está entusiasmado por construir algo nuevo.
Consideren un equipo que quiere añadir colaboración en tiempo real a un editor de documentos. En lugar de saltar directo a las opciones de implementación, Clarity preguntará qué ocurre cuando dos personas editan el mismo párrafo al mismo tiempo, y si el equipo en realidad necesita una colaboración real en tiempo real con cursores e indicadores de presencia, o si «nadie pierde su trabajo» es el verdadero requisito. Esas dos respuestas pueden dar lugar a arquitecturas muy diferentes con modos de fallo muy distintos, y aclarar esa distinción pronto puede ahorrar meses de retrabajo.
Clarity funciona como una aplicación de escritorio, una interfaz web o incrustada directo en un agente de codificación. Guía a los ingenieros a través de conversaciones estructuradas que abarcan la clarificación de problemas, la exploración de soluciones, el análisis de fallos y el seguimiento de decisiones. A medida que avanza la conversación, los resultados se escriben en un directorio .clarity-protocol/ dentro del repositorio como simples archivos markdown legibles por humanos que se confirman, revisan en pull requests y se diferencian igual que el código fuente. Recogen la declaración del problema, la justificación de la solución, el análisis de fallos y las decisiones clave tomadas a lo largo del camino.
El análisis de fallos merece un análisis más detallado, porque va mucho más allá de lo que por lo general detectaría un solo revisor. Múltiples «pensadores» de IA examinan el sistema de manera independiente desde diferentes ángulos, incluida la seguridad, factores humanos, escenarios adversariales y preocupaciones operativas. El equipo trabaja entonces los resultados junto con Clarity, para agrupar fallos relacionados, rastrear cadenas causales y planificar la gestión del edificio.
La claridad también rastrea la anticuidad en estos documentos, porque forman un grafo de dependencias. Cuando cambia una declaración de problema, Clarity sabe que la descripción de la solución y el análisis de fallos pueden necesitar ser revisados y anima al equipo a hacerlo. Las decisiones importantes se capturan con sus criterios, las opciones consideradas y la justificación detrás de cada elección, de modo que seis meses después, cualquiera del equipo pueda revisar el razonamiento completo, incluidas qué alternativas se descartaron y por qué.
El directorio .clarity-protocol/ se convierte en un artefacto compartido que todos los miembros del equipo pueden ver y aportar, y para los stakeholders que necesitan un resumen antes de una revisión, Clarity puede generar un paquete de revisión que cuenta una narrativa coherente.
RAMPART y Clarity forman parte de un movimiento más amplio hacia una seguridad en IA basada en especificaciones y nativa de la ingeniería. Complementan el trabajo de Microsoft en sistemas de política a medida: Clarity ayuda a los equipos a clarificar la intención de diseño y a capturar suposiciones; RAMPART proporciona a los equipos los bloques para escribir pruebas de seguridad de agentes concretos y mantenerlas en funcionamiento a medida que los agentes evolucionan… En conjunto, estos enfoques trasladan la seguridad de la IA de una revisión única a un conjunto de artefactos vivos que los desarrolladores pueden utilizar a lo largo de todo el ciclo de vida.
RAMPART y Clarity disponibles ahora
Tanto RAMPART como Clarity están disponibles hoy en día como proyectos de código abierto de Microsoft.
Esperamos trabajar con la comunidad. Para recibir comentarios y colaborar en su implementación en el entorno empresarial, por favor contacten con aisafetytools@microsoft.com.
Contribuciones
Microsoft RAMPART está dirigido por Bashir Partovi con contribuciones de Elliot H Omiya, Richard Lundeen, Nina Chikanov, Spencer Schoenberg y Toby Kohlenberg. Claridad es un proyecto conjunto de Yonatan Zunger, Dharmin Shah, Elliot H Omiya, Eve Kazarian, Sarah Cooley y Neil Coles. Queremos agradecer a Minsoo Thigpen, Abby Palia, Mehrnoosh Sameki, Hilary Solan, Elliot Volkman, Pete Bryan, Roman Lutz y Shiven Chawla por sus valiosos comentarios.
The post Presentamos RAMPART y Clarity: Herramientas de código abierto para incorporar seguridad al flujo de trabajo de desarrollo de Agentes appeared first on Source LATAM.
Today, AWS announces the general availability of a new AWS Local Zone in Istanbul, Türkiye, bringing AWS infrastructure closer to end users, while enabling organizations to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The AWS Local Zone in Istanbul supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
Today, AWS announces the general availability of a new AWS Local Zone in Istanbul, Türkiye, bringing AWS infrastructure closer to end users, while enabling organizations to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The AWS Local Zone in Istanbul supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
To get started, enable the AWS Local Zone in Istanbul (eu-central-1-ist-1a) from the Zones tab in the Amazon EC2 console settings or by using the ModifyAvailabilityZoneGroup API. For pricing information, visit the AWS Local Zones pricing page. To learn more, visit the AWS Local Zones overview page.
