TL;DR: At ERC 2025, Augment Code showed how a context engine can enrich prompts with semantic codebase knowledge so AI-assisted programming behaves less like autocomplete and more like a senior teammate, according to WorkOS. The editorial takeaway is that context, not raw generation, is becoming the gating factor for enterprise-ready developer AI.
At a glance
What this is: This ERC 2025 recap argues that AI coding tools only become enterprise-ready when they can retrieve and reuse codebase context, not just generate syntactically valid output.
Why it matters: That matters to IAM practitioners because the same context problem shows up in NHI, autonomous, and human-access workflows where systems need to respect prior state, policy, and lineage.
👉 Read WorkOS's ERC 2025 recap on Augment Code and context-driven AI coding
Context
AI-assisted coding often fails at the governance layer, not the syntax layer. The real gap is context: without knowing what already exists, what patterns are approved, and what constraints matter, a coding assistant can produce working output that still violates enterprise standards. In identity programmes, the same problem appears when systems act without sufficient context about entitlements, ownership, or lifecycle state.
Augment Code's demo framed context as semantic retrieval over a codebase, but the deeper identity lesson is broader. Any system that makes decisions from partial context can drift away from policy, reuse unsafe patterns, or create duplicate control paths. That is true for software development, and it is equally true for NHI governance and autonomous workflows.
Key questions
Q: How should security teams govern AI coding assistants that need codebase context?
A: Security teams should govern them as context-sensitive assistants, not as free-form generators. Define which repositories, libraries, and metadata sources may be retrieved, then verify that the assistant only receives approved context. The objective is to keep the output aligned with existing engineering standards while preventing exposure of unnecessary internal material.
Q: Why do coding assistants become risky when they lack internal context?
A: They can produce valid code that conflicts with existing patterns, duplicates logic, or bypasses established constraints. The risk is not only bad output quality. It is governance drift, because the assistant cannot reliably match the organisation's actual architecture, ownership model, or implementation conventions without the right contextual inputs.
Q: How can teams tell whether context injection is working well enough?
A: Look for whether the assistant consistently reuses approved internal libraries, respects established patterns, and avoids inventing duplicate implementations. If generated output repeatedly ignores existing project structure, the retrieval layer is not supplying enough relevant context or it is surfacing stale information.
Q: What is the difference between context-aware assistance and autonomous code execution?
A: Context-aware assistance enriches a user request and still depends on a human-driven workflow. Autonomous code execution goes further by selecting actions and timing without approval gates. That difference matters because governance for assistance centres on review and retrieval quality, while autonomy requires much stronger control over decision authority.
Technical breakdown
How context engines use semantic retrieval instead of keyword search
A context engine does more than match strings. It indexes code semantically so the system can retrieve related modules, dependencies, and prior patterns that are relevant to the task at hand. In practice, that means the assistant can enrich a short prompt with surrounding implementation detail before generating output. The important technical shift is from shallow lookup to relationship-aware retrieval, which makes the model less likely to improvise in isolation. For enterprise use, this is the difference between code generation that merely compiles and code generation that fits an existing architecture.
Practical implication: require retrieval paths that surface approved project context before an assistant writes or modifies code.
Why prompt enrichment changes the behaviour of coding assistants
Prompt enrichment adds local context to the user request before the model responds. That can include internal libraries, reusable utilities, and existing conventions, which shifts the model away from reinvention and toward controlled reuse. The architectural value is not just better output quality. It is that the assistant is constrained by what the environment already knows and uses, reducing the chance of isolated decisions that conflict with enterprise standards. This is a governance mechanism as much as a productivity feature.
Practical implication: validate what context is injected into assistant prompts and treat that pipeline as part of the control surface.
Why enterprise developer AI depends on institutional memory
Institutional memory is the accumulated history of patterns, libraries, scars, and decisions that experienced engineers carry forward. Augment's framing treated that memory as something software can index and reuse, rather than something only people hold. That matters because enterprise software work is rarely about inventing from zero. It is about making changes that remain consistent with prior architectural decisions. The technical challenge is to preserve that memory in a machine-readable form so the assistant can reason within the system's real boundaries instead of operating as a generic generator.
Practical implication: map the sources of institutional knowledge an assistant should reference, then verify they are actually available at runtime.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Context is the governance layer that decides whether AI assistance is safe or merely fluent. The article's core point is not that generation got better, but that relevance got better because the system could see more of the codebase. That same pattern appears in identity work: controls fail when systems act without the lineage, ownership, and policy context needed to make a valid decision. Practitioners should treat context access as a governed dependency, not a convenience feature.
Blind generation creates a control problem, not just a quality problem. If an assistant can produce code without understanding internal reuse patterns, it can introduce shadow logic, duplicate libraries, and inconsistent control paths. In identity terms, that is the same failure mode as isolated provisioning or policy decisions that ignore existing state. The practitioner conclusion is that context completeness is now part of secure software governance.
Context engines sharpen the line between augmentation and autonomy. The demo described a system that enriched prompts and reused existing project knowledge, which is still an assisted workflow rather than independent runtime authority. That distinction matters because many organisations are already calling tool-rich systems agentic when they are really context-aware. Teams need to classify the actor correctly before they assign governance, because the wrong label leads to the wrong control model.
Identity programmes should recognise a new named concept: context debt. Context debt is the gap between what a system needs to know to act consistently and what it can actually retrieve at decision time. As the article shows, AI tools become more enterprise-ready when that gap narrows, but the same debt exists across IAM and NHI operations whenever ownership, policy, or lineage is fragmented. Practitioners should treat context debt as a measurable governance risk, not an abstract architecture concern.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows that workflow quality often breaks before the control layer does.
- For a broader view of how context, identity, and secrets intersect, see Ultimate Guide to NHIs , Why NHI Security Matters Now.
What this signals
Context debt is emerging as a practical governance issue for teams that use AI to write or modify code. When retrieval layers cannot surface the right architectural memory, the assistant may generate output that is syntactically fine but operationally inconsistent, which creates downstream review burden for engineering and security teams.
The same pattern should shape how organisations think about identity-aware automation more broadly. A system that cannot see the right policy, lineage, or ownership context at decision time will keep recreating the same control gaps in different forms, whether the subject is code, secrets, or access flows.
For practitioners
- Define the minimum context set for AI coding tools List the internal libraries, approved patterns, and architectural constraints an assistant must see before it can generate or change code. Review that set with security, platform, and engineering leads so the context injected at runtime matches enterprise policy.
- Treat prompt enrichment as a governed control path Document which repositories, metadata sources, and retrieval services feed assistant prompts, then monitor them like any other security-sensitive integration. If the context layer changes, review the downstream effect on code quality, policy adherence, and unintended data exposure.
- Audit where context is missing or stale Identify development workflows where the assistant cannot see current reuse patterns, ownership data, or policy constraints. Those are the places where duplicate logic, unsafe shortcuts, and inconsistent implementation are most likely to appear.
- Separate assisted workflows from autonomous ones Classify whether the system is enriching prompts, selecting tools, or executing independently. That distinction determines whether governance should focus on reviewable assistance, higher-risk automation, or autonomous decision control.
Key takeaways
- AI coding tools fail most often when they lack enterprise context, not when they lack raw generation capability.
- The practical risk is governance drift, where valid-looking output bypasses internal patterns, libraries, or policy constraints.
- Teams should treat retrieval quality, prompt enrichment, and context scope as security controls, not just product features.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Context-aware coding tools affect access and use of internal resources. |
| NIST Zero Trust (SP 800-207) | The demo depends on continuous trust decisions about what context to expose. | |
| OWASP Agentic AI Top 10 | Tool-using coding assistants need governance even when they are not fully autonomous. |
Apply zero trust principles to prompt enrichment and verify every context source.
Key terms
- Context Engine: A context engine is a retrieval layer that identifies and surfaces the most relevant information for a task before a model acts. In enterprise coding, that usually means code, libraries, patterns, and metadata. The security value is that the assistant works from approved organisational context instead of guessing from prompt text alone.
- Prompt Enrichment: Prompt enrichment is the process of adding system context to a user request before the model responds. It can include repository content, policy data, or prior implementation detail. Used well, it improves relevance and consistency. Used poorly, it can expose too much information or steer the assistant with stale or incomplete context.
- Institutional Memory: Institutional memory is the practical history of architectural choices, conventions, and lessons learned inside an organisation. For AI systems, it becomes a machine-readable source of context that helps preserve consistency across teams. Without it, assistants are more likely to invent new paths that ignore existing governance and design decisions.
- Context Debt: Context debt is the gap between the information a system needs to act correctly and the information it can actually retrieve at decision time. It shows up when ownership, policy, or lineage is fragmented. The result is not just inefficiency. It is repeated governance failure in different operational forms.
Deepen your knowledge
Context-aware AI coding governance is a relevant topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for assistants that must respect existing policy and lineage, it is worth exploring.
This post draws on content published by WorkOS: Augment Code: Context Is the New Compiler. Read the original.
Published by the NHIMG editorial team on 2025-10-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org