Publicado el Deja un comentario

¿Por qué los medicamentos contra el cáncer no funcionan igual para todo el mundo?

¿Por qué los medicamentos contra el cáncer no funcionan igual para todo el mundo?

Científico usando una pipeta sobre muestras de laboratorio en un entorno de investigación.

Por: Susanna Ray, escritora de Microsoft.

El tratamiento del cáncer se ha vuelto más preciso con el tiempo, ya que los médicos clasificaron primero la enfermedad según su origen en el cuerpo y, de manera más reciente, por las mutaciones encontradas en las células cancerosas para ayudar a encontrar los fármacos adecuados para tratarla.

Pero, ¿por qué dos personas con cánceres en apariencia similares pueden responder de manera tan diferente al mismo medicamento? El investigador de Microsoft, Lorin Crawford, cree que la respuesta está en cómo se comportan en realidad los tumores, no solo en cómo se categorizan.

Un estudio de Crawford y su equipo, publicado . en Nature Methods, supone un paso importante para ayudar a la IA a entender cómo actúan e interactúan las células individuales con su entorno, ya que los investigadores aprovechan el poder de la tecnología para detectar patrones que los enfoques tradicionales pueden pasar por alto.

Logotipo “Discovered @ Microsoft” con líneas abstractas fluidas y coloridas.

La investigación forma parte del Proyecto Ex Vivo, una colaboración entre Microsoft y el Broad Institute con el apoyo del Dana-Farber Cancer Institute. El trabajo del grupo tiene como objetivo incluir el comportamiento celular en la categorización y tratamiento del cáncer, para ayudar a combatir una de las principales causas de muerte a nivel mundial, al emparejar con mayor éxito las terapias con los pacientes.

«La complejidad de la enfermedad es muy interesante a nivel científico, pero también una en la que puedes tener un impacto casi inmediato», dice Crawford. «Siento que hago algo más grande que yo. Cualquier hallazgo parece un paso adelante de alguna manera.»

Mirar más allá de las mutaciones

Parte del reto de la investigación sobre el cáncer es que los científicos pueden perder señales clave cuando prueban fármacos fuera del cuerpo. Los modelos ex vivo — células cancerosas cultivadas en laboratorios, incluidos minitumores llamados organoides — no siempre coinciden con lo que ocurre dentro de una persona. Eso significa que un medicamento que parece prometedor en una placa de Petri puede quedarse corto en un paciente.

El equipo del Proyecto Ex Vivo se centra en el «estado celular» — cómo se comportan y responden las células cancerosas a su entorno. Los estados celulares pueden influir en a qué tratamientos es sensible un tumor, a qué velocidad se desarrolla la resistencia a los fármacos y a qué tan agresiva se vuelve la enfermedad.

En el cáncer de páncreas, por ejemplo, los investigadores han observado dos estados celulares amplios asociados con diferentes resultados y respuestas al tratamiento. Pero cuando las células tumorales se cultivan en laboratorio, dice Crawford, los modelos a menudo reflejan solo uno de esos estados, lo que puede hacer que los resultados de laboratorio no coincidan con lo que ocurre en los pacientes.

«Tú y yo podemos tener la misma mutación, pero estados celulares diferentes por completo, y eso es lo que en verdad importa más adelante», dice Crawford.

Menos desajustes, mejores apuestas

Si el estado celular puede medirse de manera fiable, Crawford cree que podría cambiar el tratamiento del cáncer de dos maneras clave.

En primer lugar, podría mejorar la forma en que los pacientes se emparejan con terapias existentes y se inscriben en ensayos clínicos. Una forma más matizada de agrupar los tumores podría aumentar las probabilidades de que un tratamiento se pruebe y en verdad tenga posibilidades de funcionar.

En segundo lugar, podría abrir un nuevo camino para el propio desarrollo de fármacos. En lugar de dirigirse a una mutación, los investigadores podrían intentar atacar —o incluso cambiar— el estado subyacente de un tumor, empujándolo hacia una forma más fácil de tratar.

«El reto como clínico es entender qué características dentro del tumor de un paciente tal vez influirán en su comportamiento y respuestas a las terapias con el tiempo», dice Srivatsan Raghavan, oncólogo médico y médico-científico en Dana-Farber y codirector del Proyecto Ex Vivo. «Esta investigación pretende representar mejor estas diversas características en los modelos de cáncer y producir pruebas que reflejen la complejidad de los comportamientos tumorales que observamos en los pacientes.»

Un estadístico en un laboratorio húmedo

Acercamiento a una persona sonriendo a la cámara
Lorin Crawford. (Foto de Gregory Winter)

Crawford tomó un camino poco común en esta investigación.

Formado como matemático y estadístico, un asesor le instó a mirar más allá de las hojas de cálculo y aprender cómo se creaban los datos. Pasó la mayor parte de su trabajo de posgrado en la Universidad de Duke, donde cruzaba dos mundos, inmerso en un «laboratorio húmedo» de biología del cáncer donde los investigadores trabajaban de manera directa con células vivas, no solo con datos.

Aunque al principio parecía «estar en un país extranjero», Crawford dice que «tal vez fue la mejor decisión que he tomado nunca, desde el punto de vista profesional.»

Se dio cuenta de que su formación podría ayudar a los biólogos a gestionar la enorme cantidad de datos que se utilizan para comprender las variaciones entre pacientes y subtipos de cáncer.

«Las cosas empezaron a encajar para mí», dice.

Esa experiencia moldeó su manera de pensar hoy en día sobre el Proyecto Ex Vivo — como una manera de cerrar la brecha entre lo que funciona en el laboratorio y lo que en verdad ayuda a los pacientes. Expertos computacionales y experimentadores se sientan a resolver problemas juntos, para utilizar herramientas de IA y muestras de tumores de pacientes anónimos.

Desde un problema de laboratorio hasta la transformación del tratamiento del cáncer

Lo que comenzó como un esfuerzo de investigación enfocado en 2022 se ha expandido con rapidez, impulsado por los avances en IA. El equipo del Proyecto Ex Vivo utiliza modelos computacionales para realizar experimentos virtuales e identificar las hipótesis más prometedoras antes de invertir tiempo y dinero en el laboratorio. Las herramientas de IA pueden ayudar a predecir cómo un fármaco podría cambiar de un estado a otro, o cómo los estados se traducen entre diferentes tipos de cáncer.

Como muestran Crawford y sus colegas en el estudio de Nature Methods, los modelos de IA aprenden más al observar una amplia gama de comportamientos celulares que tan solo al recibir más datos, un hallazgo que desafía una suposición común en el campo.

«Hay una tentación real de pensar que solo ampliar los conjuntos de datos resolverá estos problemas», dice Peter Winter, codirector del Proyecto Ex Vivo e investigador principal en el Broad Institute, una institución independiente sin ánimo de lucro con estrechos vínculos con el MIT y la Universidad de Harvard. «Pero la diversidad de estados celulares en esos conjuntos de datos moldea de manera fundamental qué tipo de conocimientos pueden producir estos modelos.»

El siguiente paso es definir con claridad los estados celulares y validarlos a través de los cánceres, con el objetivo de proporcionar a los médicos mejor información para ayudar a guiar las decisiones de tratamiento.

«Hay un mundo en el que dentro de cinco años este espacio se ve muy diferente a como es ahora, lo cual me parece muy, muy alentador», dice Crawford. «La realidad de esto no está tan lejos.»

Imagen principal: Foto de Gregory Winter

Susanna Ray escribe sobre IA y tecnología, con relatos que muestran su impacto en el mundo real y examinan cómo la innovación está transformando el trabajo, los negocios y la sociedad. Antes reportó para Bloomberg News y otras grandes organizaciones internacionales de noticias en EE. UU. y en el extranjero, donde cubría temas que iban desde política y gobierno hasta negocios y aviación. Sigan su trabajo en Microsoft Source.

The post ¿Por qué los medicamentos contra el cáncer no funcionan igual para todo el mundo? appeared first on Source LATAM.

 

​The post ¿Por qué los medicamentos contra el cáncer no funcionan igual para todo el mundo? appeared first on Source LATAM.  

Publicado el Deja un comentario

Amazon RDS for PostgreSQL, MySQL, and MariaDB now supports M9g database instances

AWS Graviton5-based M9g database (DB) instances are now generally available for Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB. Graviton5-based instances provide up to a 30% performance improvement and up to a 23% price/performance improvement for on-demand pricing over Graviton4-based instances of equivalent sizes on Amazon RDS open source databases, depending on database engine, version, and workload.

AWS Graviton5 processors are the latest generation of custom-designed AWS Graviton processors built on the AWS Nitro System. M9g DB instances are available with new 24xlarge and 48xlarge sizes. With these new sizes, M9g DB instances offer up to 192 vCPU, up to 100Gbps enhanced networking bandwidth, and up to 72Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).

These instances are now available in the US East (N. Virginia, Ohio), US West (Oregon), and Europe (Frankfurt) Regions. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. For information on specific engine versions that support these DB instance types, please see the Amazon RDS documentation.

 

​AWS Graviton5-based M9g database (DB) instances are now generally available for Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB. Graviton5-based instances provide up to a 30% performance improvement and up to a 23% price/performance improvement for on-demand pricing over Graviton4-based instances of equivalent sizes on Amazon RDS open source databases, depending on database engine, version, and workload. AWS Graviton5 processors are the latest generation of custom-designed AWS Graviton processors built on the AWS Nitro System. M9g DB instances are available with new 24xlarge and 48xlarge sizes. With these new sizes, M9g DB instances offer up to 192 vCPU, up to 100Gbps enhanced networking bandwidth, and up to 72Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). These instances are now available in the US East (N. Virginia, Ohio), US West (Oregon), and Europe (Frankfurt) Regions. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. For information on specific engine versions that support these DB instance types, please see the Amazon RDS documentation.  

Publicado el Deja un comentario

AWS Glue Interactive Sessions now support Spark Connect for interactive workloads

AWS Glue Interactive Sessions now support Apache Spark Connect, using which you can now develop and run Apache Spark applications from your preferred environment, including managed notebooks in Amazon SageMaker Unified Studio, or your preferred notebook environments and IDEs like Jupyter, Visual Studio Code, while running them on AWS Glue’s serverless infrastructure without managing clusters.

With Spark Connect, you submit Spark jobs to AWS Glue Interactive Sessions using a thin client architecture that decouples your client application from the Spark execution environment. This unlocks workflows like ad hoc data exploration, iterative step-by-step debugging, and incremental PySpark job development before deploying to production, all from the tools you already use. Spark Connect also simplifies upgrades and improves stability by isolating client dependencies from the server-side Spark runtime. For observability, you get real-time session monitoring via the Spark UI, history tracking through the Spark History Server, and session management using the AWS Glue API, CLI, or SDK.

AWS Glue Interactive Sessions with Spark Connect is available in Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, Ireland, London, Paris, Stockholm), South America (São Paulo), US East (Ohio, N. Virginia), and US West (Oregon).

To get started, connect to Glue Interactive Sessions using Spark Connect from notebooks in Amazon SageMaker Unified Studio, your favorite IDE with a Python interpreter, or the AWS API, SDK, and CLI. To learn more, visit the AWS Glue Interactive Sessions documentation.

 

​AWS Glue Interactive Sessions now support Apache Spark Connect, using which you can now develop and run Apache Spark applications from your preferred environment, including managed notebooks in Amazon SageMaker Unified Studio, or your preferred notebook environments and IDEs like Jupyter, Visual Studio Code, while running them on AWS Glue’s serverless infrastructure without managing clusters. With Spark Connect, you submit Spark jobs to AWS Glue Interactive Sessions using a thin client architecture that decouples your client application from the Spark execution environment. This unlocks workflows like ad hoc data exploration, iterative step-by-step debugging, and incremental PySpark job development before deploying to production, all from the tools you already use. Spark Connect also simplifies upgrades and improves stability by isolating client dependencies from the server-side Spark runtime. For observability, you get real-time session monitoring via the Spark UI, history tracking through the Spark History Server, and session management using the AWS Glue API, CLI, or SDK. AWS Glue Interactive Sessions with Spark Connect is available in Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, Ireland, London, Paris, Stockholm), South America (São Paulo), US East (Ohio, N. Virginia), and US West (Oregon). To get started, connect to Glue Interactive Sessions using Spark Connect from notebooks in Amazon SageMaker Unified Studio, your favorite IDE with a Python interpreter, or the AWS API, SDK, and CLI. To learn more, visit the AWS Glue Interactive Sessions documentation.  

Publicado el Deja un comentario

AWS HealthOmics now streams workflow engine logs to Amazon CloudWatch in real time

AWS HealthOmics now streams workflow engine logs to Amazon CloudWatch in real time, enabling customers to monitor workflow execution progress as it happens. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.

Real-time engine log streaming accelerates iterative workflow development and debugging by giving researchers, bioinformaticians, and workflow developers immediate access to execution details during a run. The streamed engine logs provide visibility into workflow orchestration events, task scheduling details, import/export activity, and full stack traces on errors — all routed into the engine log stream in real time. Customers can set up CloudWatch alarms on log patterns to detect anomalies early, build dashboards for ongoing monitoring, and integrate with existing observability tooling.

Real-time engine log streaming is now available for Nextflow, WDL, and CWL workflow runs in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Monitoring HealthOmics with CloudWatch Logs documentation.

 

​AWS HealthOmics now streams workflow engine logs to Amazon CloudWatch in real time, enabling customers to monitor workflow execution progress as it happens. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
Real-time engine log streaming accelerates iterative workflow development and debugging by giving researchers, bioinformaticians, and workflow developers immediate access to execution details during a run. The streamed engine logs provide visibility into workflow orchestration events, task scheduling details, import/export activity, and full stack traces on errors — all routed into the engine log stream in real time. Customers can set up CloudWatch alarms on log patterns to detect anomalies early, build dashboards for ongoing monitoring, and integrate with existing observability tooling.
Real-time engine log streaming is now available for Nextflow, WDL, and CWL workflow runs in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Monitoring HealthOmics with CloudWatch Logs documentation.  

Publicado el Deja un comentario

Amazon Aurora and RDS for MySQL expand Extended Support for MySQL 5.7 through June 2029

Amazon Aurora MySQL-Compatible Edition and Amazon Relational Database Service (RDS) for MySQL now offer Amazon RDS Extended Support for MySQL 5.7 through June 30, 2029, from the previous end date of February 28, 2027. This applies to Aurora MySQL version 2 (with MySQL 5.7 compatibility) and RDS for MySQL version 5.7, giving customers additional time to plan and complete their upgrades to a supported major version while continuing to receive critical security patches and bug fixes.

RDS Extended Support delivers security patches for critical and high CVEs, bug fixes for critical operational issues, and access to AWS Support within the standard Aurora and RDS SLAs. There is no price increase with this extension, and customers using RDS Extended Support for MySQL 5.7 will continue to pay Year 3 pricing through June 30, 2029. For pricing details, see Aurora pricing and RDS for MySQL pricing.

We recommend upgrading to MySQL 8.0 or MySQL 8.4 compatible versions to benefit from the latest database features, performance improvements, and security enhancements. You can upgrade using Amazon RDS Blue/Green Deployments, in-place upgrade, or snapshot restore. To learn more, see the Aurora MySQL and RDS for MySQL user guides. This extension is available in all AWS Regions where Aurora MySQL and RDS for MySQL are available.

Amazon Aurora is designed for high performance and availability at global scale with full MySQL and PostgreSQL compatibility. Amazon RDS for MySQL, PostgreSQL, and MariaDB make it simple to set up, operate, and scale open source deployments in the cloud. Visit the getting started pages for Aurora and RDS to begin.

 

​Amazon Aurora MySQL-Compatible Edition and Amazon Relational Database Service (RDS) for MySQL now offer Amazon RDS Extended Support for MySQL 5.7 through June 30, 2029, from the previous end date of February 28, 2027. This applies to Aurora MySQL version 2 (with MySQL 5.7 compatibility) and RDS for MySQL version 5.7, giving customers additional time to plan and complete their upgrades to a supported major version while continuing to receive critical security patches and bug fixes. RDS Extended Support delivers security patches for critical and high CVEs, bug fixes for critical operational issues, and access to AWS Support within the standard Aurora and RDS SLAs. There is no price increase with this extension, and customers using RDS Extended Support for MySQL 5.7 will continue to pay Year 3 pricing through June 30, 2029. For pricing details, see Aurora pricing and RDS for MySQL pricing. We recommend upgrading to MySQL 8.0 or MySQL 8.4 compatible versions to benefit from the latest database features, performance improvements, and security enhancements. You can upgrade using Amazon RDS Blue/Green Deployments, in-place upgrade, or snapshot restore. To learn more, see the Aurora MySQL and RDS for MySQL user guides. This extension is available in all AWS Regions where Aurora MySQL and RDS for MySQL are available. Amazon Aurora is designed for high performance and availability at global scale with full MySQL and PostgreSQL compatibility. Amazon RDS for MySQL, PostgreSQL, and MariaDB make it simple to set up, operate, and scale open source deployments in the cloud. Visit the getting started pages for Aurora and RDS to begin.  

Publicado el Deja un comentario

AWS Outposts racks now support bmn-cx3a instances, the first AMD-based instances with accelerated networking on Outposts

AWS announces the availability of bmn-cx3a instances on second-generation AWS Outposts racks. Bmn-cx3a instances feature 5th Gen AMD EPYC processors with a maximum frequency of 4.1 GHz and NVIDIA ConnectX-7 (CX7) network interface cards, delivering up to 800 Gbps of bare-metal accelerated network bandwidth operating at near line rate.

Bmn-cx3a instances offer up to 256 cores and 1.5 TB of memory across two sizes, bmn-cx3a.metal-32xl and bmn-cx3a.metal-64xl, with 2x 8 TB NVMe SSD storage. With native Layer 2 (L2) multicast and hardware Precision Time Protocol (PTP) support, bmn-cx3a instances are designed for high-throughput workloads such as real-time market data ingestion and distribution, market and risk analytics, telecom 5G core network applications, and media distribution.

Bmn-cx3a instances on AWS Outposts racks are available in all countries and regions where second-generation Outposts racks are supported. For a current list of AWS Regions and countries/territories where Outposts racks are supported, check out the Outposts rack FAQs page.

 

​AWS announces the availability of bmn-cx3a instances on second-generation AWS Outposts racks. Bmn-cx3a instances feature 5th Gen AMD EPYC processors with a maximum frequency of 4.1 GHz and NVIDIA ConnectX-7 (CX7) network interface cards, delivering up to 800 Gbps of bare-metal accelerated network bandwidth operating at near line rate. Bmn-cx3a instances offer up to 256 cores and 1.5 TB of memory across two sizes, bmn-cx3a.metal-32xl and bmn-cx3a.metal-64xl, with 2x 8 TB NVMe SSD storage. With native Layer 2 (L2) multicast and hardware Precision Time Protocol (PTP) support, bmn-cx3a instances are designed for high-throughput workloads such as real-time market data ingestion and distribution, market and risk analytics, telecom 5G core network applications, and media distribution. Bmn-cx3a instances on AWS Outposts racks are available in all countries and regions where second-generation Outposts racks are supported. For a current list of AWS Regions and countries/territories where Outposts racks are supported, check out the Outposts rack FAQs page.  

Publicado el Deja un comentario

Reconstruir la actividad de la IA en investigaciones

Reconstruir la actividad de la IA en investigaciones

Información de valor del Red Team Global

Por: Phillip Misner y el Red Team de IA de Microsoft.

Los sistemas de IA forman ahora parte del trabajo diario. Los investigadores necesitan una manera coherente de reconstruir lo que ocurrió en su interior.

Los equipos de seguridad ya investigan actividades relacionadas con Microsoft 365 Copilot y los servicios de IA de Azure, desde intentos de inyección rápida hasta accesos inesperados a datos. Esas señales son observables. Sin estructura, no forman una explicación coherente de lo ocurrido.

Las interacciones de IA generan telemetría en Microsoft Purview, Defender y Sentinel. Esa telemetría captura quién inició una interacción, cuándo ocurrió y qué recursos estuvieron involucrados. Proporciona la base para reconstruir la actividad de IA en entornos empresariales. Convierte esas señales en una investigación.

Para ayudar a abordar ese desafío, hemos publicado un nuevo manual de investigación para Microsoft 365 Copilot y los servicios de IA de Azure. El manual proporciona un enfoque estructurado para investigar actividades relacionadas con la IA por medio de la telemetría ya disponible en los productos de seguridad de Microsoft. 

La metodología sigue una secuencia de alcance–contexto–señal. Las investigaciones comienzan con la identificación de quién interactuó con los sistemas de IA, cuándo ocurrió la actividad y qué servicios participaron. A partir de ahí, los investigadores amplían el contexto de los recursos: a qué accedió el sistema, qué datos pudieron haber sido expuestos y cómo esa actividad se alinea con el comportamiento esperado. Las señales de detección, incluidos los intentos de inyección rápida, patrones de uso anómalos o alertas de exposición de credenciales, se evalúan dentro de esa cadena de actividad más amplia.

La telemetría de IA se construye primero con metadatos, al brindar identidad, tiempo y contexto de recursos a través de las interacciones. Esa estructura es lo que traslada las investigaciones de señales aisladas a un relato coherente de lo ocurrido. Cuando se analizan en conjunto, estos elementos permiten a los investigadores establecer lo ocurrido, comprender el impacto y determinar si la actividad refleja un uso normal, violaciones de políticas o indicadores de compromiso.

El manual de estrategia operacionaliza este enfoque en los servicios de IA de Microsoft 365 Copilot y Azure. Reúne la configuración, consultas y patrones de detección necesarios en un único modelo funcional — que cubre referencias de esquemas, consultas KQL y lógica de detección — lo que permite a los investigadores seguir la actividad de la IA a través de herramientas con menos pivotes ad hoc. También extiende ese modelo a sistemas basados en agentes, donde la imagen investigativa se amplía: qué agentes se despliegan, cómo están configurados, a qué datos están autorizados a acceder y si esa autorización se utilizó como se esperaba. 

El resultado es práctico. Los equipos de respuesta pueden pasar de señales aisladas a una reconstrucción de la actividad observada: analizar el uso de la IA, entender qué datos se accedieron durante las interacciones y evaluar si el comportamiento observado es coherente con el uso normal, violaciones de políticas o indicadores de condiciones de amenaza activas en los servicios de seguridad de Microsoft.

A medida que la IA se convierte en parte de los flujos de trabajo cotidianos de los negocios, los equipos de respuesta necesitan el mismo rigor investigativo que aplican a endpoints, identidades e infraestructura de nube. La capacidad de determinar qué ocurrió, qué datos estuvieron involucrados y si la actividad fue autorizada se convierte con rapidez en una capacidad central de respuesta a incidentes.

El manual les da las herramientas para responderla. Descárguenlo aquí: https://aka.ms/AIIRplaybook 

The post Reconstruir la actividad de la IA en investigaciones appeared first on Source LATAM.

 

​The post Reconstruir la actividad de la IA en investigaciones appeared first on Source LATAM.  

Publicado el Deja un comentario

AWS DevOps Agent adds release management capability (preview)

AWS DevOps Agent now offers a release management capability in preview, reviewing code changes for release readiness and running autonomous release testing to help you ship code to production safely and with confidence. With this addition, AWS DevOps Agent now works across both delivery and operations. It accelerates and validates the deployment of code changes, then keeps your applications running optimally across AWS, multicloud, and on-prem environments, so your team ships faster, reduces MTTR, and achieves operational excellence.

With release readiness review, AWS DevOps Agent evaluates code changes for production safety during code generation by checking for drift from your internal standards, dependency impacts, and access controls. It maps cross-repository dependencies to surface breaking changes before commit and uses deterministic proofs to review that infrastructure changes do not drift from AWS Well-Architected best practices. With release testing, AWS DevOps Agent generates and runs test plans for web and API-based applications in customer-provisioned environments, catching regressions, UX issues, and integration failures a human reviewer may miss.

To get started with the preview, connect your code repositories and pipelines in your AWS DevOps Agent space. AWS DevOps Agent release management is available in the US East (N. Virginia) Region and at no additional cost during the preview period. For the list of AWS Regions where AWS DevOps Agent production operations is available, see the supported Regions table. For pricing of production operations features, which are generally available, see AWS DevOps Agent pricing.

 

​AWS DevOps Agent now offers a release management capability in preview, reviewing code changes for release readiness and running autonomous release testing to help you ship code to production safely and with confidence. With this addition, AWS DevOps Agent now works across both delivery and operations. It accelerates and validates the deployment of code changes, then keeps your applications running optimally across AWS, multicloud, and on-prem environments, so your team ships faster, reduces MTTR, and achieves operational excellence. With release readiness review, AWS DevOps Agent evaluates code changes for production safety during code generation by checking for drift from your internal standards, dependency impacts, and access controls. It maps cross-repository dependencies to surface breaking changes before commit and uses deterministic proofs to review that infrastructure changes do not drift from AWS Well-Architected best practices. With release testing, AWS DevOps Agent generates and runs test plans for web and API-based applications in customer-provisioned environments, catching regressions, UX issues, and integration failures a human reviewer may miss. To get started with the preview, connect your code repositories and pipelines in your AWS DevOps Agent space. AWS DevOps Agent release management is available in the US East (N. Virginia) Region and at no additional cost during the preview period. For the list of AWS Regions where AWS DevOps Agent production operations is available, see the supported Regions table. For pricing of production operations features, which are generally available, see AWS DevOps Agent pricing.  

Publicado el Deja un comentario

AgentCore harness in now generally available

Today, AWS announces the general availability of the managed agent harness in Amazon Bedrock AgentCore, taking teams from idea to working agents in minutes. An agent is more than a model. If the model is the brain, the harness is the body: everything the brain needs to get work done. It runs the orchestration loop, executes tools, manages the context window, persists state across turns, recovers from failures, and isolates each session. The harness shapes how well an agent performs as much as the model does, and building a durable one is where most teams spend their time today. AgentCore harness provides that layer as a managed capability. Instead of coding the loop, customers define an agent in configuration: the model it uses, the tools it calls, the skills it accesses, and the instructions it follows, and AgentCore assembles and runs that loop. From that single definition, a production-grade agent runs in minutes in its own isolated environment, with a filesystem and shell, memory across sessions, skills including the AWS-curated catalog, and web browsing. This is not a starter tool teams outgrow: the configuration they start with is what they operate at scale, and when custom orchestration is needed, the harness exports to code on the same platform without rebuilding anything.

Besides speed, AgentCore decouples the harness from the model. Customers can choose any model and switch providers mid-session without losing context or touching agent logic, for example planning with one model and writing code with another. The harness is also one piece of a single platform, not a hosting layer wrapped around a framework. It reaches tools through the same gateway that enforces security policies, and connects the agent to organizational knowledge and web search. Identity, memory, and observability come from that same platform, so every agent action is governed and traced from the first call without additional wiring. When a use case needs custom orchestration, a single CLI command exports the harness to Strands-based code on the same compute and primitives, with Claude Agent SDK coming soon as an export target. The agent declared on day one is the agent that runs at the thousandth, on the same foundation throughout.

AgentCore harness is generally available today in all AWS Commercial Regions where AgentCore is available. Learn more using the documentation

 

​Today, AWS announces the general availability of the managed agent harness in Amazon Bedrock AgentCore, taking teams from idea to working agents in minutes. An agent is more than a model. If the model is the brain, the harness is the body: everything the brain needs to get work done. It runs the orchestration loop, executes tools, manages the context window, persists state across turns, recovers from failures, and isolates each session. The harness shapes how well an agent performs as much as the model does, and building a durable one is where most teams spend their time today. AgentCore harness provides that layer as a managed capability. Instead of coding the loop, customers define an agent in configuration: the model it uses, the tools it calls, the skills it accesses, and the instructions it follows, and AgentCore assembles and runs that loop. From that single definition, a production-grade agent runs in minutes in its own isolated environment, with a filesystem and shell, memory across sessions, skills including the AWS-curated catalog, and web browsing. This is not a starter tool teams outgrow: the configuration they start with is what they operate at scale, and when custom orchestration is needed, the harness exports to code on the same platform without rebuilding anything. Besides speed, AgentCore decouples the harness from the model. Customers can choose any model and switch providers mid-session without losing context or touching agent logic, for example planning with one model and writing code with another. The harness is also one piece of a single platform, not a hosting layer wrapped around a framework. It reaches tools through the same gateway that enforces security policies, and connects the agent to organizational knowledge and web search. Identity, memory, and observability come from that same platform, so every agent action is governed and traced from the first call without additional wiring. When a use case needs custom orchestration, a single CLI command exports the harness to Strands-based code on the same compute and primitives, with Claude Agent SDK coming soon as an export target. The agent declared on day one is the agent that runs at the thousandth, on the same foundation throughout. AgentCore harness is generally available today in all AWS Commercial Regions where AgentCore is available. Learn more using the documentation.   

Publicado el Deja un comentario

Amazon Bedrock AgentCore now supports Bedrock Guardrails in policy

Today, AWS announces that Amazon Bedrock AgentCore now supports Bedrock Guardrails in policy, giving enterprises deeper safety and security controls as they scale AI agents in production. AgentCore policy is an authorization capability within Amazon Bedrock AgentCore that controls which actions AI agents are authorized to take. Guardrails give enterprises defenses against the top security and safety risks with AI agent workloads, including prompt injection attacks and sensitive data exposure.

Guardrails can evaluate the outputs of every authorized agent action and inputs of every call to a gateway target (tools, agents, and models) in real-time, helping detect and block prompt injection attacks, harmful content, and sensitive information exposure before they reach downstream systems. Guardrail results are evaluated in policy at the AgentCore gateway perimeter, outside the agent’s code, ensuring consistent enforcement regardless of agent autonomy. All policy evaluations are logged via AgentCore observability for optimization and auditing purposes.

AgentCore policy works with existing AgentCore gateway deployments and requires no new infrastructure. Customers author policies through natural language or policy-as-code, with consumption-based pricing for policy evaluations.

Bedrock Guardrails are available in policy in US East (N. Virginia), Europe (London), Europe (Stockholm), Asia Pacific (Sydney), and Asia Pacific (Tokyo). To learn more, visit Amazon Bedrock AgentCore or explore the documentation.

 

​Today, AWS announces that Amazon Bedrock AgentCore now supports Bedrock Guardrails in policy, giving enterprises deeper safety and security controls as they scale AI agents in production. AgentCore policy is an authorization capability within Amazon Bedrock AgentCore that controls which actions AI agents are authorized to take. Guardrails give enterprises defenses against the top security and safety risks with AI agent workloads, including prompt injection attacks and sensitive data exposure. Guardrails can evaluate the outputs of every authorized agent action and inputs of every call to a gateway target (tools, agents, and models) in real-time, helping detect and block prompt injection attacks, harmful content, and sensitive information exposure before they reach downstream systems. Guardrail results are evaluated in policy at the AgentCore gateway perimeter, outside the agent’s code, ensuring consistent enforcement regardless of agent autonomy. All policy evaluations are logged via AgentCore observability for optimization and auditing purposes. AgentCore policy works with existing AgentCore gateway deployments and requires no new infrastructure. Customers author policies through natural language or policy-as-code, with consumption-based pricing for policy evaluations. Bedrock Guardrails are available in policy in US East (N. Virginia), Europe (London), Europe (Stockholm), Asia Pacific (Sydney), and Asia Pacific (Tokyo). To learn more, visit Amazon Bedrock AgentCore or explore the documentation.