DEV Community: Krishnam Murarka

Zero Trust for Business Applications

Krishnam Murarka — Thu, 23 Jul 2026 13:16:19 +0000

Originally published on the Edilec blog: https://edilec.com/blog/sec-4108/zero-trust-for-business-applications/

Zero trust replaces implicit confidence based on network location with explicit, risk-informed decisions about each resource request. For a business application, that means authenticating people and workloads, authorizing the requested action on the specific resource, limiting session and credential scope, and using telemetry to reassess access. It does not mean distrusting employees as people, nor does it describe one product.

Define scope in business and risk terms

Bring together application owners, identity teams, endpoint operations, data stewards and support to map high-value resources and current access paths. Trace real requests from a person or workload through authentication, authorization and data access, including remote and partner scenarios.

Inventory protected resources, data sensitivity, users, workloads and existing access paths.
Express authorization in business actions and objects, not only network zones or broad roles.
Strengthen identity, lifecycle and recovery according to risk.
Give services verifiable identities and protect service-to-service calls.
Collect policy, device, session and resource telemetry without making one signal absolute.
Migrate one high-value journey with fallback and support before expanding.

Design the lifecycle, decisions and boundaries

Represent access as a decision over subject, workload, device, resource, action and context. Enforcement must occur at the resource-facing layer for each meaningful request, not only at network entry.

Resolve implementation details early

Assign owners for resource classification, identity lifecycle, device evidence, authorization policy, enforcement and incident response. Document token lifetime, revocation, policy distribution, telemetry freshness, regional dependencies, privacy limits and emergency access.

Roll out with observable gates

Baseline the current outcome, delay, failure demand and risk before changing the process.
Build a thin end-to-end path and test contracts, permissions, telemetry and recovery.
Run in simulation, shadow or limited-production mode where the control permits it.
Release to a named cohort with an owner, support coverage, stop conditions and rollback steps.
Review technical signals and business outcomes together; investigate segment differences.
Expand only when exceptions are handled reliably and operating documentation matches reality.
Retire the previous path, credentials, jobs and access after evidence and retention needs are satisfied.

Operate the capability after launch

Establish governance around protected resources and access policies, not merely the zero-trust tooling. Review privileged roles, policy exceptions, service identities, signal quality and resources lacking enforcement. Workload identity is essential because modern applications call one another more often than people call each service directly. Give each deployable workload a distinct identity, authenticate both ends where feasible and authorize the specific API operation.

Key takeaways

Start from a complete business outcome and the evidence needed to trust it.
Make identity, authority, state, exception handling and ownership explicit.
Design failure, recovery and reconciliation before expanding volume.
Roll out to controlled cohorts with measurable gates and practiced rollback.
Treat configuration, policy, access and retirement as continuing product work.

More from Edilec: RBAC design for internal tools (edilec.com/blog/sec-9002) and Edilec's cybersecurity services (edilec.com/services/cybersecurity).

CI/CD Pipelines for Growing Products: Fast Releases, Verifiable Recovery

Krishnam Murarka — Thu, 23 Jul 2026 13:14:36 +0000

Originally published on the Edilec blog: https://edilec.com/blog/cld-3102/ci-cd-pipelines-for-growing-products/

CI/CD pipelines for growing products should reduce the uncertainty of change, not merely reduce the number of clicks before production. A dependable pipeline answers five questions for every release: what changed, who reviewed it, which immutable artifact was tested, which policy allowed it to advance, and how the team will detect and recover from harm.

Define the release contract

Write down the unit that moves through the pipeline: container digest, signed package, mobile build or versioned function bundle. Define the environments it crosses, required evidence, approval authority, exposure strategy and recovery objective. Classify changes by consequence: a documentation-only update, a stateless API patch, a schema migration and an identity-policy change should not share an identical path.

Create one trusted build artifact

A commit should enter a controlled build environment with pinned tools and dependencies. The pipeline compiles or packages once, runs tests against the resulting artifact, records dependency and build metadata, and publishes it to an immutable repository. Rebuilding separately for staging and production weakens the claim that production received what was tested.

Order checks for fast, useful feedback

Put formatting, static analysis, unit tests, secret detection and configuration validation close to the commit because they are fast and deterministic. Run contract and integration tests against realistic boundaries. Reserve expensive performance and resilience suites for changes or stages where they materially reduce risk.

Secure pipeline identities and execution

A delivery pipeline is a privileged production system. Use workload identity federation or another short-lived credential mechanism instead of static cloud keys. Scope each stage to the environment and action it needs, and separate build from deployment identities.

Separate deployment from release exposure

Deployment places the artifact in an environment; release exposes users or traffic. Feature flags, canaries, rings and blue-green strategies let teams separate those moments. Compare errors, latency, saturation and a product-specific success signal against a valid baseline before expanding exposure.

Rehearse recovery across data boundaries

Rollback is not simply redeploying the previous binary. A release may change schemas, produce events old consumers cannot parse, or start an irreversible external action. Prefer backward-compatible expand-and-contract migrations, and test restoration of schema, state, queues and flags, not only compute.

Key takeaways

Build an artifact once, identify it by digest, and promote that exact artifact across environments.
Apply fast deterministic checks early and risk-sensitive checks before exposure.
Keep credentials short-lived and scoped; protect pipeline configuration and runners as production assets.
Separate deployment from full release so exposure can increase gradually.
Rehearse rollback and forward repair with database, queue and compatibility effects included.

More from Edilec: Deployment rollbacks architecture guide (edilec.com/blog/km-cld-0012) and Edilec's cloud and DevOps services (edilec.com/services/cloud-devops).

RAG for Company Knowledge and Support: Architecture, Controls and Rollout

Krishnam Murarka — Thu, 23 Jul 2026 13:03:35 +0000

Originally published on the Edilec blog: https://edilec.com/blog/ai-1080/rag-for-company-knowledge-and-support/

Retrieval-augmented generation, or RAG, can help employees and support teams answer questions from approved policies, product documentation, procedures and case history. The system searches a controlled corpus at request time, supplies selected passages to a model and asks it to answer from that evidence. This makes knowledge easier to update, but it does not make every answer correct. A production design must treat content quality, retrieval, authorization, generation and human escalation as separate controls.

What RAG does and where it fits

Ingest approved sources, divide them into retrievable units, attach metadata and permissions, create lexical and vector representations, retrieve candidates, rank them, assemble a bounded context and generate an answer with evidence references. RAG is an information system with a generative interface, not merely a prompt attached to a document folder.

Retrieval is not authorization

A relevant document may still be restricted. Enforce access before passages enter model context, and test authorization at query time. Hiding a citation after generation does not undo disclosure to the model or user.

Prepare the knowledge base before tuning the model

Duplicate procedures, expired policies and contradictory product notes will produce inconsistent answers regardless of model quality. Inventory sources and classify each as authoritative, supplementary or excluded. Chunking should follow meaning, not an arbitrary character count.

Design retrieval and answering as observable stages

Lexical search is strong for error codes, names and distinctive phrases; vector search helps when user wording differs from the documents. Hybrid retrieval runs both and combines their candidates. Do not assume more retrieved chunks always improves answers.

Evaluate the pipeline, not only the final prose

Build a representative evaluation set from real, de-identified questions, including common requests, rare terms, typos, ambiguous wording, restricted documents and questions with no answer. Measure recall, ranking quality, groundedness, citation correctness, abstention quality and authorization.

A staged RAG rollout plan

Inventory and govern one bounded domain with named source owners.
Build retrieval first, and tune it against labeled questions before adding generation.
Add answer generation offline and test citations and no-answer behavior.
Run a limited internal pilot with required review.
Expand with gates only when authorization, freshness and relevance meet criteria.
Operate continuously and retain a tested rollback path.

Key takeaways

Treat RAG as a governed information system, not a prompt attached to a document folder.
Clean, classify and assign owners to source content before tuning retrieval.
Enforce user and document permissions before evidence enters model context.
Evaluate retrieval, groundedness, citations, abstention and operations separately.
Start with a bounded, reviewable use case and expand only through measured gates.

More from Edilec: How AI agents work in business workflows (edilec.com/blog/ai-1024) and Edilec's AI automation services (edilec.com/services/ai-automation).

How AI Agents Work in Business Workflows: Architecture, Controls and Rollout

Krishnam Murarka — Thu, 23 Jul 2026 13:01:21 +0000

Originally published on the Edilec blog: https://edilec.com/blog/ai-1024/how-ai-agents-work-in-business-workflows/

An AI agent becomes business software when it can pursue a bounded goal, obtain approved context, choose from permitted tools, observe results and stop safely. The language model is only one component. Identity, workflow state, APIs, approval rules, logs and fallback queues determine whether the agent produces dependable work or merely an impressive demonstration.

Workflow, agent or assistant

A conventional workflow follows paths written in code. An assistant generates or retrieves information while a person remains the operator. An agent chooses its next step within a defined action space. Use the least autonomous pattern that solves the problem.

The agent loop

The orchestrator sends a goal, instructions, current state and available tool schemas to a model. The model returns a proposed tool call, a user-facing answer, a clarification request or a stop signal. The application validates the proposal, executes an allowed action, records the result and returns an observation for the next turn.

Goal: a specific outcome, not a vague instruction.
Context: the minimum records and policies needed for the decision.
Action: a read, calculation, draft or write operation through a typed tool contract.
Observation: the tool result or approval decision.
Stop condition: success, timeout, budget exhaustion or human escalation.

Tools and memory do different jobs

A tool is an enforceable interface to the outside world with a narrow purpose and typed input schema. Memory persists information across turns; treat durable memory as application data with a defined source, access control and deletion path.

Failure modes and controls

Wrong context, prompt injection, excessive action, looping and silent partial failure are the common failure modes. Narrow tools, least privilege, approval gates, rate limits and idempotent execution contain them.

A staged rollout

Define one workflow, owner and success criteria.
Map every data source and action; classify read, draft or write.
Build an offline scenario set before connecting production tools.
Run in shadow mode where the agent proposes but does not act.
Move to draft mode for a small cohort and capture edits and approvals.
Enable one low-risk reversible action with narrow permissions.
Review quality, exceptions and cost, then expand only with evidence.

Key takeaways

The model proposes; the application authorizes, executes and records.
Agents are justified by variable multi-step work, not every automation opportunity.
Tools should be narrow contracts; memory should be governed application data.
Evaluation must cover the complete trajectory and real business outcome.
Autonomy should increase one reversible capability at a time.

More from Edilec: RAG for company knowledge and support (edilec.com/blog/ai-1080) and Edilec's AI automation services (edilec.com/services/ai-automation).