IT Hello
search
Category index

Architect

325 articles

325 ARTICLES

Why AI apps fail in production (And how Google solved it)
ARCHITECT

Why AI apps fail in production (And how Google solved it)

We are living in the golden age of the weekend AI side project. Thanks to agentic engineering and LLMs, the time to go from a blank IDE to a functional local application has dropped from quarters to hours. You can build your wildest ideas over a cup of coffee. But inside an enterprise ecosystem with rigid infrastructure and millions of users, vibe coding hits an invisible wall. Your local prototype falls apart against corporate networks, cascading errors, or getting blocked by leadership terrified of operational volatility. The data is sobering: only 5% of AI prototypes make it to production; the other 95% fall into the validation abyss. For developers, watching people on social media ship lightning-fast AI deployments while you’re stuck in endless validation loops is maddening. To figure out how to bridge this chasm, I went into the engineering trenches at YouTube to see how they manage this exact speed-versus-risk paradox. What I discovered completely rewrites the playbook on AI software development lifecycle (SDLC) design. The risk-vs-speed paradox When you are solo-building, failure is cheap. Writing agentic code is like piloting a nimble jet fighter—if an AI agent misbehaves, you rewrite the prompt and instantly restart the server. But as AI engineering leader Addy Osmani points out in our premiere of Emergent, unconstrained agentic orchestration inside an enterprise introduces an unpredictable blast radius. Addy recalls running ten parallel agents on a personal project, context-hopping and pushing code based purely on quick previews. The technical debt accumulated fast, breaking two apps catastrophically because the modifications weren’t properly isolated. Amplify that risk to the scale of YouTube. Its infrastructure handles billions of users on a robust, 20-year-old codebase. It is essentially a public utility; you cannot risk overloading it with experimental technical debt. Protecting a platform of this scale requires extensive, slow guardrails: By the time you build a primitive demo through this pipeline, the underlying AI models have evolved, leaving your idea out of date. How do you move at lightspeed while minimizing systemic risk? YouTube’s AI prototyping stack Deepmind and former YouTube software engineer, Benji Bear, solved this puzzle not by accelerating reviews, but by changing infrastructure philosophy. He and his team built a prototyping stack — a unified design-to-code lifecycle platform that completely decouples rapid experimentation from mainline production servers. It systematically solves the two primary friction points of developer velocity. Decoupling the data layer Isolating a standalone app completely causes a “blank canvas” problem where you can’t test prototypes against realistic conditions. To solve this, developers bootstrap their ideas using pre-built Google AI Studio templates. These templates hook into a proxy server set up on Google Cloud for prototype-approved read-only data. This instantly grants the prototype pre-authenticated, read-only API access to live metadata bundles (playlists, videos, channels) via strict tokens. Developers get the technical accuracy of live production parameters without any ability to write back to, pollute, or crash core databases. Live UI injection When a concept requires true real-world validation, the stack offers client-side YouTube Extension wrappers. This wrapper acts as glue code, allowing developers to inject their experimental features directly into the actual, live production web surface of YouTube. Code-split chunk safeguards isolate this from production binaries, allowing prototype updates to deploy to a safe staging environment in minutes. The result? YouTube went from taking multiple quarters to vet an idea to launching several successful prototypes — including YouTube Recap and Ask YouTube — straight to user research studies (UXR) in weeks. Embrace throw-away code Implementing this stack requires a profound psychological shift. Engineers are trained to treat code as permanent infrastructure, polishing and refactoring it until it’s pristine. But Benji’s core enterprise AI philosophy here is simple: Embrace throw-away code. Google AI Studio prototypes are meant to be messy with some technical debt; their objective is to validate product-market fit using quantitative data. Trying to refactor a chaotic, AI-generated app into an enterprise codebase is an architectural trap that can create friction. But because Google AI Studio builds your prototype directly onto a mirrored version of production infrastructure, you establish a highly accurate baseline from day one. You still discard the messy, AI-generated script, but when an idea proves successful, rewriting it for production becomes significantly faster, cheaper, and safely positioned later in the development lifecycle—giving you a verified blueprint to code against rather than a blank canvas. Move fast without breaking things The core realization here is that a 95% failure rate isn’t a bug — it is the strategy. We should design environments that encourage our teams to fail more frequently and safely. AI has plummeted the cost of code generation. Consequently, our roles are shifting from syntax gatekeepers to system architects. Our job is to design the bridges, read-only sandboxes, and isolated pipelines that empower teams to test wild ideas without triggering catastrophic meltdowns. The biggest risk isn’t breaking a server with messy AI code; it’s missing the technological moment because validation loops are too slow. By building structural constraints that make failure safe, you give your team the freedom to run at hyper-speed. To see the full technical breakdown, interview clips with YouTube’s core infrastructure engineers, and a look inside the Google AI Studio Proto-Stack, watch our premiere episode of Emergent on YouTube.

5 MIN READ arrow_forward
Supercharging pgvector: 4x faster HNSW vector search with AlloyDB
ARCHITECT

Supercharging pgvector: 4x faster HNSW vector search with AlloyDB

AlloyDB is a fully managed, PostgreSQL-compatible database service built for your most demanding enterprise workloads. It combines the best of open source PostgreSQL with Google’s advanced technology, offering massive scalability, high availability, and native AI capabilities. It serves as a performant relational store, a unified backend for vector and full text search, and an analytics engine that is up to 100x faster than standard PostgreSQL. Vector search is the foundation of modern AI and Retrieval Augmented Generation (RAG) applications. For developers using AlloyDB and other PostgreSQL databases, pgvector is a widely adopted extension for storing, indexing, and querying vector embeddings, and HNSW (Hierarchical Navigable Small World) is a highly efficient graph-based algorithm designed for approximate nearest neighbor search across multi-layered structures. With columnar engine accelerated HNSW in AlloyDB (now in preview), you can achieve up to 4x higher queries per second (QPS) for vector search compared to standard PostgreSQL HNSW. Enterprise AI applications face a constant trade-off between speed and accuracy. When searching through millions or billions of vectors, maximizing Queries per Second (QPS) without sacrificing search quality (recall) is critical for scaling production workloads. The PostgreSQL pgvector extension offers HNSW as one of the indexes that can speed up Approximate Nearest Neighbor (ANN) searches. Let’s dive deep into how AlloyDB solves the speed vs. accuracy trade-off. Note: While this post focuses on HNSW performance, it’s worth noting that HNSW is just one part of AlloyDB’s advanced vector toolkit. AlloyDB also features ScaNN—a cutting-edge index backed by over 14 years of Google Research—giving you the flexibility to choose the perfect index for your workload. Additionally, for use cases demanding absolute precision, standard k-nearest neighbor (KNN) search is always available for 100% recall. Check out our Choose a Vector Index Guide to see how they stack up. aside_block <ListValue: [StructValue([(’title’, ‘Get started with a 30-day AlloyDB free trial instance’), (‘body’, <wagtail.rich_text.RichText object at 0x7efbe89e25b0>), (‘btn_text’, ‘Start building for free’), (‘href’, ‘http://goo.gle/try_alloydb’), (‘image’, None)])]> First, what is the AlloyDB columnar engine? The AlloyDB columnar engine is a built-in, in-memory cache that automatically stores frequently queried data in a specialized, scan-optimized columnar format. It allows AlloyDB to handle heavy analytical queries up to 100x faster than standard PostgreSQL. Additionally, it accelerates ANN searches by storing the index in memory, using a vectorized memory layout for fast traversals, and bypassing standard PostgreSQL buffer manager overhead. Performance visualization To understand the real-world performance characteristics of columnar engine Accelerated HNSW, we plotted standard QPS vs Recall curves for the GloVe 100 Angular dataset by searching more than 1M records with a limit of 100. Running this benchmark script yields the following visualization: Note: These measurements were taken on an AlloyDB C4A 16vCPU machine. Due to the inherent randomness in HNSW graph building, results may slightly vary across runs. The data reveals two transformative benefits: Massive performance throughput gains: For any given target recall (e.g. 0.95), QPS is increased by approximately 4.2x to 4.9x. This allows you to handle significantly more concurrent vector searches on the same hardware. Significant recall (accuracy) improvement: Conversely, at a fixed QPS level, columnar engine accelerated HNSW provides a substantial boost in recall. For example, we saw that at ~350 QPS (in the above chart), enabling the columnar engine improves recall from roughly 0.78 to over 0.94 – a 0.163 recall gain. This means your AI applications get much more accurate results without any latency impact. It is important to note that the baseline (blue line) already represents the index being fully cached in the PostgreSQL shared buffer cache. The performance gains shown here are not the result of moving data from disk to RAM, but rather the result of a more efficient memory architecture. How it works: Columnar engine Accelerated HNSW In standard PostgreSQL architectures, index operations utilize the shared buffer cache. Even when data is fully in-memory, the database still incurs significant overhead from the buffer manager, which must handle operations such as page pinning and unpinning, lock acquisition, buffer table lookups, and Least Recently Used (LRU) management. AlloyDB’s columnar engine is a built-in, in-memory cache that stores data in a specialized, scan-optimized format. With this release, AlloyDB can use columnar engine accelerated HNSW to: Pin the index: The pgvector HNSW index is pinned (kept persistently in-memory to ensure fast access) directly into the columnar engine’s memory. Vectorized access: It utilizes a memory layout specifically designed for the high-concurrency, pointer-heavy traversals required by HNSW graphs. Bypass buffer overhead: By navigating the graph in a specialized memory space, AlloyDB avoids the standard buffer manager bottlenecks. This architectural shift is what enables the dramatic QPS and recall improvements shown above, even when comparing against a fully-cached standard index. Why it Matters For enterprise-scale applications, this isn’t just about a faster database—it’s about cost and quality: Reduced infrastructure costs: Achieve the same performance with significantly lower compute resources. Better AI accuracy: Reach higher recall and quality at speeds that were previously only possible for “draft” (high-speed, lower-accuracy results) quality search. No application changes required: Because this is built into AlloyDB, you get these gains using the same standard pgvector SQL syntax. Note that the columnar engine does utilize memory, but it is highly compressed and meticulously managed. Because the engine stores vector data in an efficient columnar format, the memory footprint is minimal compared to the massive performance gains—making it a highly favorable trade-off for enterprise workloads. Quick Start Guide To try out columnar engine accelerated HNSW in AlloyDB, follow these steps: 1. Enable the columnar engine and index caching Ensure that both google_columnar_engine.enabled and google_columnar_engine.enable_index_caching flags are set to on for your AlloyDB instance. 2. Add the HNSW Index to columnar engine Once your HNSW index is created via pgvector, execute the following SQL command to cache it in the columnar engine: code_block <ListValue: [StructValue([(‘code’, “SELECT google_columnar_engine_add_index(’<hnsw_index_name>’);”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe8972100>)])]> 3. Additional Resources New to AlloyDB? Discover AlloyDB with a 30-day free trial. Google Colab Notebook: An end-to-end Python script to ingest the GloVe dataset, create indexes, and plot Recall vs QPS curves. Is HNSW the right vector index choice for your use case? Check our ‘Choose a vector index in AlloyDB AI’ guide.

5 MIN READ arrow_forward
Now in preview: Find and fix software vulnerabilities with CodeMender
ARCHITECT

Now in preview: Find and fix software vulnerabilities with CodeMender

As adversarial AI threats accelerate attacks on code, security teams must counter them with machine-speed defenses that can automate code remediation and fight AI with AI. CodeMender is our managed code security agent, and starting today, we’re bringing its code scanning and remediation capabilities directly to you in preview. CodeMender offers access to our generally available models via Gemini Enterprise Agent Platform, or it can be deployed as a core component of AI Threat Defense. CodeMender also aligns with our multi-model approach, so you can choose the right model to optimize for cost, speed, and deep scanning performance. It will support third-party frontier model options later this year. How to find and fix code vulnerabilities autonomously with Google CodeMender. Watch this overview of CodeMender in Gemini Enterprise Agent Platform. CodeMender can help you advance from passive scanning to automated code remediation, and reduce zero-day risk. It examines and remediates existing code security issues without sacrificing development velocity by: Deploying the best-fit model. You can choose from multiple models to optimize for costs, speed, deep scanning, and coding performance. Automating machine-scale remediation. You can now eliminate remediation bottlenecks caused by manual verification and patching, while keeping developers in the loop. Prioritizing fixes by exploitability. You can run proof-of-concept exploits and execute simulations to verify that vulnerabilities in the code are exploitable, and prioritize resources on fixing the most critical issues first. Find and fix vulnerabilities with AI Born from Google DeepMind’s pioneering AI research, CodeMender transforms vulnerability management from a manual bottleneck into an autonomous, high-speed system. Your developers and security practitioners can automatically scan software for flaws, verify them with executable exploits, and remediate them with tested code fixes. “At Salesforce, trust is our number one value, and protecting customer data means continually raising the bar for how we find, validate, and mitigate risks. CodeMender brings AI into a critical part of the security lifecycle by accelerating the path from validated vulnerability to tested fix. As AI reshapes the threat landscape, capabilities like this help strengthen resilience and give our customers the confidence to keep innovating,” said Iain Mulholland, CISO, Salesforce. “CodeMender consistently identified critical vulnerabilities that our other AI-enabled tools completely missed. It doesn’t just find theoretical flaws — it proves the immediate risk and delivers targeted, validated fixes that secure our environment without disrupting core business logic,” said Scott Ponte, head, Security Operations, Robinhood. “CodeMender is fast, comprehensive, and genuinely ambitious about closing the loop from detection to fix, enabling teams to secure their software supply chain without losing velocity,” said Ashwin Kannan, principal AI engineer, Office of the CTO, Palo Alto Networks. How the CodeMender agent works We’ve fine-tuned CodeMender’s harness to be continuously updated with the latest Google DeepMind research, including the up-to-date agent skills, security tools, and system prompts. Operating in the secure-by-design Agent Platform, CodeMender is protected by enterprise-grade, built-in governance and security guardrails, including secure traffic routing through your VPC, data isolation and encryption, and zero retention of source code data. As an agent, it can integrate with existing continuous integration and continuous delivery (CI/CD) workflows, or run directly in local developer environments using a lightweight command-line interface (CLI) client. You can also configure CodeMender to scan and analyze code in a sandbox that you manage. The agent connects to your code repositories and works with developer tools, such as VS Code and Antigravity, to safely analyze first-party, open-source, and third-party software. Scan: Find hidden vulnerabilities with flexible model scanning CodeMender scans for top vulnerability classes and understands the unique context, goals, and functionality of your software repositories and applications. Scan: Discovered new vulnerabilities and categorized by severity and type. CodeMender’s harness with security context helps you discover sophisticated vulnerabilities that static and model-only scanning miss. These scans look for hard-to-find vulnerabilities like memory corruption, injection, web security issues, cryptographic flaws, and insecure data handling. CodeMender supports common software languages including C/C++, Go, Java, Python, Ruby, Rust, and TypeScript. Verify: Simulate and verify exploits to reduce noise CodeMender can help cut alert fatigue and false positives by proving a vulnerability presents a legitimate risk before fixing it. The agent goes beyond static code-pattern analysis by simulating an attack with exploit code it builds and runs in an isolated, customer-managed sandbox. Verify: Creates verification plan and builds and tests exploits in your sandbox environment. The agent uses this proof-of-concept exploit to verify that the security flaw poses a legitimate risk. This critical verification phase allows your security practitioners and developers to prioritize validated risks by eliminating false positives. Remediate: Automatically generate and test code fixes Identifying risky security flaws is only half the battle. Once a vulnerability is verified, CodeMender automatically generates a secure patch to resolve the issue. The fix is delivered as a code difference directly in developer tools, so it can be integrated into existing development workflows. Remediate: Generates and tests code fix with code diff for developer review and approval. CodeMender further strengthens the fix by using LLM-as-a-judge to ensure it doesn’t disrupt existing application functionality. You can even provide context on your codebase’s distinct coding conventions and styles so that CodeMender generates code that matches it. Developers remain in full control, manually reviewing and approving CodeMender’s patches before any code is committed to the repository. CodeMender in AI Threat Defense When leveraged as part of AI Threat Defense, Wiz orchestrates agentic application security, analyzing applications to prioritize investigations. It calls CodeMender to scan code (coming soon), enrich findings within the Wiz Security Graph with deployment context, and trigger Wiz Red Agent for AI pentesting to prove exploitability, ensuring that teams focus on the highest-risk vulnerabilities. Through Wiz, AI Threat Defense calls CodeMender to scan code, enrich findings, and trigger AI pentesting. Wiz serves as a command center for governing and scaling remediation in AI Threat Defense. The Wiz Green Agent orchestrates this lifecycle by directing CodeMender to generate and test high-fidelity patches enriched with application context from the Security Graph. This workflow empowers teams to resolve complex vulnerabilities with unprecedented speed and precision. How to get started with CodeMender Consistent with our multi-model approach, CodeMender can help you optimize for cost, speed, and deep scanning performance. You can use CodeMender with our generally available Gemini models via Agent Platform, or deploy it as a core component of AI Threat Defense. Separately, CodeMender with Gemini 3.5 Flash Cyber will be exclusively available to a small set of governments and trusted partners. We plan to expand this access over time. CodeMender is a critical step towards a continuous, self-healing agentic software development lifecycle, a future where code is autonomously secured, validated, and patched before it ever hits production. You can learn more about CodeMender and review the documentation here.

6 MIN READ arrow_forward
How the 2026 World Cup affected Internet traffic
ARCHITECT

How the 2026 World Cup affected Internet traffic

We analyzed global HTTP traffic to explore how kickoff times, streaming habits, and hydration breaks reshaped online activity worldwide. From late-night traffic surges to halftime browsing spikes, here is how the world connected during the global tournament.

1 MIN READ arrow_forward
Generosity Under Conditions: Hardening Google Cloud Access Management
ARCHITECT

Generosity Under Conditions: Hardening Google Cloud Access Management

In Google Cloud, Identity and Access Management (IAM) helps you maintain access control over your cloud resources and operations. While it includes other features, this is its primary purpose. If you ever tried to harden security over your application, you know the importance of the Principle of Least Privilege (PoLP) ‒ grant the absolute minimum permissions to your users and workloads to allow them to perform their tasks. You reach it through use of predefined roles and custom roles and setting up a combination of Allow and Deny IAM policies at project, folder, or organization level. Using a combination of Allow and Deny policies along the resource hierarchy is an effective way to control access. This approach lets you enforce PoLP across many different scenarios. The existing flexible control can be insufficient when resources in the project are shared between multiple workloads or used by more than one team. In many such scenarios, it is possible to bind IAM policies to a specific resource in the project. For example, consider the difference between granting the role Artifact Registry Editor (roles/artifactregistry.editor) on a project vs. granting it on a specific repository in the project. In the former case, the access is granted to ANY repository in the project. In the latter case, users will have the editor access only to a specific repository. However, binding IAM policies to a resource or service level isn’t always possible. This is when it is time to use IAM conditions. Let’s look at two distinct examples that demonstrate the power of conditions when hardening access management: one for traditional administrative roles, and one for modern AI integrations. Use Case 1: Constraining the Power of Admins This case demonstrates how to restrict the specific operations that broad IAM roles are authorized to perform. You can easily scope administrative privileges for managing specific resources in a project by granting a “resource creator” role at the project level and an editor role on a selected resource. It is far more challenging to constrain IAM Admin Roles that are intended to grant access to operations rather than specific resources. A representative example would be the IAM Admin role (roles/iam.admin). Users granted this role can grant themselves any other role or create a new one. It greatly exceeds practical needs. The first step is to narrow the access by using the Project IAM Admin role (roles/resourcemanager.projectIamAdmin) that provides administrative privileges only at the level of the project. It is possible, however, to restrict the granted privileges even further. For example, suppose you grant the Project IAM Admin role to your builder service account that creates resources and deploys workloads. The workloads only need access to the BigQuery and Agent Platform APIs (formerly Vertex APIs) and permission to write logs and traces. For such a case you can use the following gcloud CLI command or its alternative in Terraform: code_block <ListValue: [StructValue([(‘code’, ‘gcloud projects add-iam-policy-binding “${PROJECT_ID}” \\r\n –member=“serviceAccount:${SA_MAIL}” \\r\n –role=“roles/resourcemanager.projectIamAdmin” \\r\n –condition="^:^\\r\ntitle=LimitedIAMAdmin:\\r\nexpression=api.getAttribute('iam.googleapis.com/modifiedGrantsByRole', [])\\r\n.hasOnly([\\r\n'roles/aiplatform.user',\\r\n'roles/bigquery.jobUser',\\r\n'roles/bigquery.dataViewer',\\r\n'roles/cloudtrace.agent',\\r\n'roles/logging.logWriter'\\r\n])"’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe83c3af0>)])]> The value of the condition parameter is defined using Common Expression Language (CEL) syntax. First it customizes a field delimiter to be a colon instead of a comma and then describes the condition fields title and expression. The expression field uses functions for API attributes to identify which roles are being granted to allow granting only the roles in the comma delimited list. The same operation in Terraform will look very similar. Using input variables instead of environment variables, it will look like this: code_block <ListValue: [StructValue([(‘code’, ‘resource “google_project_iam_member” “limited_project_iam_admin” {\r\n project = var.project_id\r\n role = “roles/resourcemanager.projectIamAdmin”\r\n member = “serviceAccount:${var.sa_email}"\r\n condition {\r\n title = “LimitedIAMAdmin”\r\n expression = «-EOT\r\n api.getAttribute('iam.googleapis.com/modifiedGrantsByRole', []).hasOnly([\r\n 'roles/aiplatform.user',\r\n 'roles/bigquery.jobUser',\r\n 'roles/bigquery.dataViewer',\r\n 'roles/cloudtrace.agent',\r\n 'roles/logging.logWriter'\r\n ])\r\n EOT\r\n }\r\n}’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe97a00a0>)])]> Use Case 2: Control over MCP Server Access This case is about hardening access to specific services behind a single set of permissions. Google exposes access to a subset of cloud resources and services via MCP Servers that expose Model Context Protocol (MCP) endpoints. The access to these servers is granted using the predefined MCP Tool User (roles/mcp.toolUser) role. This role grants access to ALL available MCP servers (for a project where an IAM policy is set). Using conditions helps to narrow the access to a specific MCP server. code_block <ListValue: [StructValue([(‘code’, ‘gcloud projects add-iam-policy-binding $PROJECT_ID \\r\n –member=“serviceAccount:$SA_EMAIL” \\r\n –role=“roles/mcp.toolUser” \\r\n –condition="^:^\\r\ntitle=bigquery_mcp_server_only:\\r\nexpression=resource.service == 'bigquery.googleapis.com'”’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe97a06d0>)])]> Notice that the value compared to the resource.service attribute is not the MCP server endpoint (which is bigquery.googleapis.com/mcp) but the endpoint of the service. It is possible to narrow the access scope further to the level of the specific MCP tools. For this you will need to use API attributes again. The following expression limits the service account access to the level of only two BigQuery MCP tools. code_block <ListValue: [StructValue([(‘code’, “expression=api.getAttribute(‘mcp.googleapis.com/tool.name’, ‘’) in [\\r\n’mcp_bigquery-mcp_execute_sql’,\\r\n’mcp_bigquery-mcp_execute_sql_readonly’\\r\n]”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe97a0340>)])]> Note that if you condition the IAM policy binding at the MCP tool level, you don’t need to validate the resource.service attribute. For experimenting with MCP server access you can use the Getting Started with Google MCP Servers codelab and modify its gcloud projects add-iam-policy-binding commands. And Even More Besides enforcing precise control when using predefined roles, IAM conditions let you craft access management based on the time of the request. For example, the following condition’s expression allows access only during daytime on weekdays: code_block <ListValue: [StructValue([(‘code’, “expression=request.time.getHours(‘Europe/Berlin’) >= 9 &&\\r\nrequest.time.getHours(‘Europe/Berlin’) <= 17 &&\\r\nrequest.time.getDayOfWeek(‘Europe/Berlin’) >= 1 &&\\r\nrequest.time.getDayOfWeek(‘Europe/Berlin’) <= 5”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7efbe97a02b0>)])]> The expression limits access from 9 o’clock in the morning to 5 o’clock in the evening according to the “Europe/Berlin” timezone from Monday to Friday (days of the week range from 0 to 6, starting with Sunday). IAM conditions allow controlling the identity of the actor using the principal attributes. However, it can easily become an anti-pattern. The recommended practice is to control the identity of actors allowed to use the policy through the list of the IAM policy’s principals instead of using the conditions. Conclusion and More Resources While IAM conditions give you surgical precision over Allow policies, you can take your defense-in-depth strategy even further with IAM Deny policies. With Deny Policies you can grant access using the predefined IAM roles with Allow policies and remove excessive permissions of the role to enforce PoLP. See the following resources for additional information about Deny policies: Identify the permissions that are supported in deny policies. Get the format of principal identifiers in deny policies. Find out how to troubleshoot access issues with deny policies. Learn more about denying access to principals. Read the blog post about Build defense in depth. You can use Google Skills for hands-on experience with IAM policies.

6 MIN READ arrow_forward
Why your agent needs access to your documentation
ARCHITECT

Why your agent needs access to your documentation

What 1,192 agent conversations taught us about knowledge base search A few months ago we shipped an agent inside our own product. It lives in our web app and lets users ask questions about their deployment,…

1 MIN READ arrow_forward