eyko SmartSecurity for JD Edwards

Modern data platforms need more than a single security switch. eyko’s platform is designed around a multi layer security model that starts at the source system, carries through the data model, and is enforced at query time for every user and use case.

This article summarizes that architecture so that security and systems teams can understand how eyko protects JD Edwards and non JDE data in analytics and AI scenarios. A full technical whitepaper is available as a downloadable supplement for deeper design and implementation details.

The three pillars of eyko’s security model

eyko’s security architecture is built on three complementary pillars:

Pillar 1: Foundational security through data selection

Only the data that is actually needed for analytics is brought into the eyko model. This reduces the security surface area and simplifies governance.
Pillar 2: Integrating JD Edwards SmartSecurity

Existing SmartSecurity rules in JDE are reused as the baseline for who can see which records.
Pillar 3: Native row and field level security in eyko

eyko adds its own security rules to extend or refine access, including for non JDE sources, without having to change JDE itself.

Together these pillars support a defense in depth approach, so that data is controlled:

At ingestion, by deciding which sources, environments, companies, and tables are included.
In the model, by defining entities that respect JDE security and business relationships.
At query time, by enforcing row and field level rules for each user and role.

Pillar 1: Foundational security through data selection

The first design decision is what data to bring into eyko at all. This is where security starts.

Typical practices include:

Restricting source systems, environments, and companies to only those required for analytics.
Excluding tables or columns that contain sensitive or unnecessary attributes.
Segmenting streams so that highly sensitive domains, for example HR or payroll, are modeled separately if needed.

By controlling the footprint at the ingestion layer, eyko reduces the risk that sensitive but unused data is exposed in downstream models or AI workloads.

Pillar 2: Reusing JD Edwards SmartSecurity

For organizations using JD Edwards, SmartSecurity is often the primary system of record for data access rules. eyko treats SmartSecurity as the foundation rather than reimplementing it.

Key aspects of this integration:

eyko connects to JDE environments in a way that respects SmartSecurity definitions for users and roles.
Row level filters defined in SmartSecurity, for example company, business unit, or other key attributes, are applied as the baseline when users query JDE sourced data in eyko.
Changes to SmartSecurity propagate automatically to eyko, so central JDE security administration remains the source of truth.

This allows security teams to preserve their existing JDE governance model while enabling modern analytics and AI use cases.

Pillar 3: Native row and field level security in eyko

Not all requirements can or should be implemented in JDE. eyko provides native security controls inside the platform to fill these gaps.

Typical uses of eyko native security include:

Restricting visibility of specific fields, for example hiding cost or margin metrics for certain roles.
Applying additional row level filters that depend on the analytics model, for example limiting access to a derived “customer segment” or “profitability band”.
Securing data sourced from non JDE systems, such as CRM, ticketing, or e commerce platforms, with consistent rules across sources.

These rules are defined at the model and design layer in eyko and are evaluated dynamically at query time, so they apply consistently whether a user is in dashboards, ad hoc analysis, or AI assisted experiences.

The hybrid model

Combining SmartSecurity and native rules

In practice, most customers use a hybrid model where:

JD Edwards SmartSecurity provides the foundational row level controls for JDE sourced entities.
eyko native rules extend and refine access, and secure additional entities created from multiple sources.

Examples of hybrid patterns:

Start from SmartSecurity filtered base entities, then define secured views that further filter or mask fields for specific groups, such as finance, operations, or external partners.
Combine JDE entities with non JDE data into higher level entities, and secure those using eyko rules while still honoring SmartSecurity on the JDE components.
Implement role based field masking where SmartSecurity handles “which rows” and eyko handles “which columns”.

This approach lets organizations respect existing JDE security investments while gaining the flexibility required for modern analytics and AI.

Security propagation across the model

A core architectural principle in eyko is security propagation. Security is not defined independently on every object. Instead, secured base entities are reused so that their filters automatically propagate to downstream entities, reports, and AI prompts.

In practice this means:

If a base entity is secured by SmartSecurity or eyko native rules, any entity built on top of it inherits those rules automatically.
Designers are encouraged to model sensitive data once in well defined secured entities, rather than recreating the same logic in multiple places.
When new reports or AI use cases are added, they automatically respect existing security, because they query through the secured entities.

This reduces duplication, lowers the risk of inconsistent access, and simplifies governance as models evolve.

Implementation responsibilities

eyko emphasizes a clear division of responsibilities:

JDE security administrators

Own SmartSecurity definitions that control baseline access to JDE sources.
System and data architects

Decide which data is brought into eyko, how streams and entities are modeled, and where security boundaries should sit.
eyko designers and administrators

Configure native row and field level rules, secure non JDE entities, and ensure security propagates correctly through designs.

By aligning responsibilities in this way, organizations can operate a consistent, auditable security model across both operational systems and analytics.

Conclusion and downloadable whitepaper

In summary, eyko delivers a multi-layerlayer security architecture that:

Minimizes exposure through careful data selection.
Reuses JD Edwards SmartSecurity as the trusted baseline.
Adds flexible native row and field level controls for all sources.
Ensures security propagates through the data model into every analytic and AI workload.

For readers who want a more formal, written walkthrough of these same concepts, including the three pillars, example group based rules, the hybrid model, and guidance on security propagation and maintenance, you can attach the whitepaper as a downloadable supplement to this article:

eyko Platform Security Architecture, A Technical Whitepaper for System Architects and Security Administrators